EasyAnt project
Hi all, Xavier Hanin and I are currently working on a new build system fully based on Apache Ant / Apache Ivy, here is a short information. Welcome to EasyAnt Easyant is a toolbox focusing on easing project build processes. It's based on Apache Ant and Apache Ivy, and allows for maximum flexibily, improved integration in existing build systems and provides conventions and guidelines. Our goals are : - to simplify build process by providing a set of ready to use build scrips (or modules) to ease implemantation of a build system. - to provide conventions and guidelines - to leverage your ant knowledge (no need to learn yet another language) - to stay flexible : - what about conventions ? : Even if Easyant came with a lot of conventions, we never lock you in. - what about modules ? : You can easily adapt it to your projects. The architecture of Easyant allow you to easily extends existing modules, and to provide your own one. - what about if i have an existing project? As Easyant is fully based on ant, you can keep existing project with old school ant script. This can simplify migrations. Currently Easyant provides module for : - java compilation - javadoc generation - scala compilation - scaladoc - unit tests (Junit / TestNG) - emma coverage - checkstyle - packaging jar / war application - dependency management (using Apache Ivy) - publication (using Apache Ivy) Source code Easyant is released under Apache License 2.0. Sources can be found here SVN Url : http://easyant.abrm.info/svn Login : anonymous pass: (empty) Google group http://easyant.abrm.info/trac/wiki/WikiStart#Googlegroup A google group is accessible here http://groups.google.com/group/easyant Our website is accessible here http://easyant.abrm.info Jean Louis Boudart
EasyAnt
Hi all, Xavier Hanin and I are working on a new build system fully based on Apache Ant / Apache Ivy, here is a short information. Welcome to EasyAnt Easyant is a toolbox focusing on easing project build processes. It's based on Apache Ant and Apache Ivy, and allows for maximum flexibily, improved integration in existing build systems and provides conventions and guidelines. Our goals are : - to simplify build process by providing a set of ready to use build scrips (or modules) to ease implemantation of a build system. - to provide conventions and guidelines - to leverage your ant knowledge (no need to learn yet another language) - to stay flexible : - what about conventions ? : Even if Easyant came with a lot of conventions, we never lock you in. - what about modules ? : You can easily adapt it to your projects. The architecture of Easyant allow you to easily extends existing modules, and to provide your own one. - what about if i have an existing project? As Easyant is fully based on ant, you can keep existing project with old school ant script. This can simplify migrations. Currently Easyant provides module for : - java compilation - javadoc generation - scala compilation - scaladoc - unit tests (Junit / TestNG) - emma coverage - checkstyle - packaging jar / war application - dependency management (using Apache Ivy) - publication (using Apache Ivy) Source code Easyant is released under Apache License 2.0. Sources can be found here SVN Url : http://easyant.abrm.info/svn Login : anonymous pass: (empty) Google group http://easyant.abrm.info/trac/wiki/WikiStart#Googlegroup A google group is accessible here http://groups.google.com/group/easyant Our website is accessible here http://easyant.abrm.info Jean Louis Boudart
Re: EasyAnt project
Thanks for your support. We've made a patch of ant-core to introduce some concept used by easyant. This patch : - introduce phase concept : A kind of target that contains *ONLY*dependencies, useful to make build modules easily reusable in a standard build (more infos at http://easyant.abrm.info/trac/wiki/tasks/phase ) - introduce two different kind of import (what we call use / extends) : - import extends : Equivalents to the current import task (The terminology import could thus be used either for extends or use, each being a subclass of import.) (more infos at http://easyant.abrm.info/trac/wiki/tasks/extends ) - use : A way to import ant file using namespace ( more infos at http://easyant.abrm.info/trac/wiki/tasks/use ) - modify project-help to display phases separated from targets (We'd need to make the help more helpful, by classifying targets, or hiding some of them maybe with different levels of help = not yet implemented) You can see this patch at http://easyant.abrm.info/trac/browser/trunk/src/main/patches/ant-697121-easyant-patch.diff Feel free to give us a feedback on our patch or on EasyAnt. Regards, Jean Louis Boudart 2008/10/21 Stefan Bodewig [EMAIL PROTECTED] On Fri, 17 Oct 2008, Jean-Louis BOUDART [EMAIL PROTECTED] wrote: Easyant is a toolbox focusing on easing project build processes. It's based on Apache Ant and Apache Ivy, and allows for maximum flexibily, improved integration in existing build systems and provides conventions and guidelines. Cool. If you need changes in Ant's core to make things easier, not only Xavier is a committer but you can be sure you'll find support on this list. A google group is accessible here http://groups.google.com/group/easyant I'm trying to subscribe right now, but I've always been too dumb to work with googlegoups' interface (I do not want to use my gmail account as the address to subscribe with) - I usually figure it out after a few failed attempts 8-) Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: EasyAnt project
2008/10/27 Stefan Bodewig [EMAIL PROTECTED] I've given in and used my googlemail account for the easyant group, grmbl. Nice :) Google 1 vs Stefan Bodewig 0 Round 2... Fight ! I'll look through the patch and will comment/start new threads for them later (maybe more than just a bit later). Since you are using Ant's trunk anyway, if we decide to add parts of the patch or a similar patch to achieve the same, you could modifiy your patch and required baseline of ant, right? No problem. - introduce phase concept : A kind of target that contains *ONLY*dependencies, I'm not good at names. I understand why this is a good name in the context of EasyAnt but struggle with the same name when applied to pure Ant. I recall being confused by the phase mapping when Xavier first suggested it. We can use write java classes without using abstract classes / interface and all that stuff? :p Phase is like an abstract task it doesn't introduce order in your build script but introduce a kind of comportement Exemple: phase name=report description=generate reports related to your project/ target name=javadoc depends=whatever phase=report /target target name=checstyle-report depends=checkstyle,whatever phase=report ... /target By typing ant checkstyle-report you only generate checkstyle report. By typing ant javadoc you only generate javadoc report. By typing ant report you generate ALL targets related to the report phase. This allow you more modularity than creating a target like : target name=report depends=javadoc,checkstyle-report/ Is it more clear? - introduce two different kind of import (what we call use / extends) I think you will quickly find support for this separation here, in particular if we throw in user definded prefixes where the writer of the build file that uses another build file gets to define the prefix of targets - hi, DD ;-) I really not understand what you mean here :'( - modify project-help to display phases separated from targets If the concept of a phase is different from that of a plain target, then it deserve its own logging, agreed. Cheers Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: EasyAnt project
FWIW, I'm not fond of the phase name either. What you describe is better described as a target-group, with any target being able to join the group at will, and where there's no implicit intra-group dependencies, and no body to the target-group (i.e. the group is abstract in a way). I like the target-group name too :) I think target-group should only depend on another target-group target-group name=test-compile description=... / target-group name=test description=... depends=test-compile/ Just as you seem to propose, I'd be in favor of requiring your phase or my target-group to be explicitly declared before it can be referenced. This would avoid typos implicitly creating groups unbeknown to the build writer / fat fingered individual ;-) I agree, we must declared it explicitly! Just Stefan pocking gentle fun at me, because I vehemently argued for what you propose when import was introduced. If you look back at the archives, I was strongly against using the import*ed* build file name in the import*er*, as it needlessly coupled the two, when good compartmentalization is essential to flexible and scalable designs (I even proposed the ability of the import*er* to give its own prefix as well). I also argued for separate import/include, just like in XSLT. In both cases my objections were ignored. So it's interesting that a separate group of Frenchmen now wants these same changes in Ant. Is this a French invasion ? :p When I argue what I believe is the right way to do something, and my point is being dismissed in favor of a lesser design (at least to me), this typically leaves me frustrated. Stefan remue le couteau dans la plaie comme on dit chez nous ;-) --DD Ok now i understand 2008/10/29 Stefan Bodewig [EMAIL PROTECTED] BTW, targets (and your phase variant of it) are not tasks. My bad, i wanted to write abstract target but my fingers has wrotten something different. Maybe i've taken too much coffee yesterday. (Interresting my fingers can write something different of i'm thinking about... ) I like Dominique's target group more than the name phase. And I understand that EasyAnt builds on the Maven concept to make things easier for users switching. Without EasyAnt, the name would be a bad choice inside Ant. There is no problem to rename phase concept in target-group. I think as you said target group is more self-explicit. We'll probably need support and feedback on others modifications/concept on EasyAnt that could be included in ant or ivy. For example we need : - to add visibility feature on target (something close to private / public) (ant related) As we want to introduce prefix on some kind of import it could be nice to have a way to display only public target when you type ant -p. And to provide a way to see All targets (public / private) when we type ant myPrefix -p that should display all the targets available for the import we've called myPrefix. - to provide support for parent module (ivy related) This is probably close to this issue https://issues.apache.org/jira/browse/IVY-742 Even if i think support for parent module is not only related dependency. We could imagine that parent support allow you to inherit dependencies / configurations / licences / homeurl / etc ...? What do you think about that? Cheers!
Re: EasyAnt project
UP Is there some news about our patch or about ProjectHelper class / Target class refactoring? Jean Louis 2008/10/29 Stefan Bodewig [EMAIL PROTECTED] On Wed, 29 Oct 2008, Matt Benson [EMAIL PROTECTED] wrote: --- Stefan Bodewig [EMAIL PROTECTED] wrote: On Wed, 29 Oct 2008, Matt Benson [EMAIL PROTECTED] wrote: 3. Define an ant.project.class magic property to easily allow the user to specify an extended Project class to use. 4. EasyAnt has its own Project, Target, and Executor implementations that know about phases. If EasyAnt used a ProjectHelper of its own, it probably could get away without a custom Project. A custom Executor may be a good idea, though. EasyAnt would need its own wrapper script or an invocation would become cumbersome, though. How is a custom Project class(name) more cumbersome to configure than a custom ProjectHelper? Not at all, sorry, I didn't mean to say that. EasyAnt would need a wrapper anyway in order to configure Project class/ProjectHelper, Target class and Executor. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: EasyAnt use/extends vs import
IIUC EasyAnt solits the two use-cases found for import into two logical tasks. * you never want to override a target, you just want to reuse them: use That's an include to me. Rename use into include, and I'm +1, I'm not bound to names. +1 =) I'm not totally sure whether the as-attribute would make sense for extends as well, EasyAnt currently silently ignores it in that case. It makes as much sense in import as it does in include to me, i.e. to restore proper compartmentalization of the builds. I'd probably want to allow it for symmetry as well, but I haven't thought through all implications. I'm not sure that adding an as-attribute make sense for extends. In our POC you can import with use mode the same file with different prefix. exemple : project name=Abstract-Module ... /project project name=Concret-Module1 use file=Abstract-Module as AbstractModuleConcret1/ ... /project project name=Concret-Module2 use file=Abstract-Module as AbstractModuleConcret2/ ... /project project name=genericBuild extends file=Concret-Module1/ extends file=Concret-Module2/ /project I guess adding an as attribute on extends is like having only one import mode where we can add prefix, and i'm not sure this is the solution. IMHO we need those two kind of import: - extends similar to the actual import - use is like a Rich import that support namespace and that allow you to import many time the same build script with different namespace. That's why i think as attribute should be used only with use. What do you think about it? I don't think we should invent new terminology (use/extends) for something that already exists (import) and it's natural equivalent to use (include, which doesn't exist). Then we need to stretch the difference. Two new names would increas awareness that import does something special. What's missing from the above is the notion of TargetGroup to implement the phase concept of EasyAnt (and Maven I guess). True. To me those concepts are orthogonal and I'd like to have separate discussions on them (and picked this topic to be first). Nice :)
Re: EasyAnt use/extends vs import
[EMAIL PROTECTED] wrote: I'm not sure that adding an as-attribute make sense for extends. In our POC you can import with use mode the same file with different prefix. exemple : project name=Abstract-Module ... /project project name=Concret-Module1 use file=Abstract-Module as AbstractModuleConcret1/ ... /project project name=Concret-Module2 use file=Abstract-Module as AbstractModuleConcret2/ ... /project project name=genericBuild extends file=Concret-Module1/ extends file=Concret-Module2/ /project What I've argued before is that the 'as' attribute used by a build should only be visible to that build. Any other build that uses it (English meaning of use :) should not be aware of this attribute. This way both Concrete-Model1 and 2 can use the same as, and it's genericBuild that's then forced to use two different 'as' attributes for them to be able to distinguish them. It's analogs to Java's inheritance, where a derived class can only refer explicitly to its direct parent's methods, and not any of its ancestors (like in C++). In other words, you can only bypass the normal virtual dispatch of method if it's a method of your parent. There's no reason for genericBuild to directly reference Abstract-Module. Abstract-Module basically became part-of Concret-Module1 and 2, and is invisible to genericBuild, unless genericBuild also directly import/includes it. Failing to do this, you couldn't safely refactor Concrete-Module1 and 2, without possibly breaking genericBuild. I think this is a good idea, even if i have no idea of how to implement it. Maybe we can improve target visibility (something close to private / public). Project help should be able to display public target of a given submodule. Ah, it looks to me that I'm again failing to get my view across. Since I'm no longer actively using Ant like I used to, I'll take a step back and stop arguing the above points, which are probably incompatible with the (simplistic?) way Ant deals with import and target addressing (by simple prefixing). I'm really interested by your point of view :), maybe because you seems to be on of those who tries to faire avancer le schmilblick comme on dis chez nous ;) - use is like a Rich import that support namespace and that allow you to import many time the same build script with different namespace. And I thought use was like an include ;) i.e. less than import, while it's actually more. --DD
Re: EasyAnt use/extends vs import
EasyAnt switched to ant-713373 Every things seems ok, except prefix separator should be applied on targets (ie. in targetHelper) too. Here is the patch that include phase concept + the quick fix to prefix separator : http://easyant.abrm.info/trac/browser/trunk/src/main/patches/ant-713373-easyant-patch.diff Thanks a lot Stefan ! 2008/11/12 Stefan Bodewig [EMAIL PROTECTED] On 2008-11-12, Stefan Bodewig [EMAIL PROTECTED] wrote: On 2008-11-12, Jean-Louis BOUDART [EMAIL PROTECTED] wrote: I think that using include should allow user to have nested prefix, should be pretty easy to fix and it makes some sense in the include case. In addition to this, could it be possible to have a parametrized prefix separator? Yep. It will need yet another modification to ProjectHelper for the case where no as attribute has been given and we use the project name, but still is pretty straight forward to do. Both have been added in revision 713373. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: EasyAnt use/extends vs import
Ooops my bad, i've merged with my previous patch :$
This is now fixed in:
http://easyant.abrm.info/trac/browser/trunk/src/main/patches/ant-713373-easyant-patch.diff
The patch contains only things related to phases concept.
In addition to this, i think that we should add a way to disable prefixing,
i have a use case in easyant where i don't want to use prefix.
In the patch i removed this control:
if (configuredValue != null configuredValue.length() == 0) {
configuredValue = null;
}
This allow me to have a dirty fix to import a build script without prefix :)
by setting as attribute to an empty string (import file=... as=/).
2008/11/12 Stefan Bodewig [EMAIL PROTECTED]
On 2008-11-12, Jean-Louis BOUDART [EMAIL PROTECTED] wrote:
EasyAnt switched to ant-713373
Every things seems ok, except prefix separator should be applied on
targets
(ie. in targetHelper) too.
http://easyant.abrm.info/trac/browser/trunk/src/main/patches/ant-713373-easyant-patch.diff
Both places where your patch replaces . with prefixSeparator (line
861 and line 888 of the original) are correct in svn, you must be
using some inconsistent state since your patch won't apply.
I'm a bit puzzled since I never committed a version that had
prefixSeparator only in one place but not the other two.
Stefan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: EasyAnt use/extends vs import
Hi Stefan, First of all i would like to thank you for your interests on our patch. I'm currently trying to switch to trunk Head revision and i'm getting some troubles with nested inclusion. I think that using include should allow user to have nested prefix, here is a short example: project name=abstract target name=myAbstractTarget description=i'm abstract ... /target /project project name=A include file=abstact as=myPrefix/ target name=mySpecificTargetFromA depends=myPrefix.myAbstractTarget description=i'm A ... /target /project project name=B include file=A as=iLikeNestedPrefix/ target name=mySpecificTargetFromB depends=iLikeNestedPrefix.mySpecificTargetFromA description=i'm B ... /target /project project name=generic build extends file=B/ /project By typing ant -p i should see something like : B.mySpecificTargetFromB -- i'm B B.iLikeNestedPrefix.mySpecificTargetFromA -- i'm A B.iLikeNestedPrefix.myPrefix.myAbstractTarget -- i'm abstract In our previous patch it was done by ImportTask ( http://easyant.abrm.info/trac/browser/trunk/src/main/patches/ant-697121-easyant-patch.diffl168-l187) What do you think about it? In addition to this, could it be possible to have a parametrized prefix separator? I guess you've added a . betwen prefix and target name (ex: myPrefix.myTarget), could we have something more flexible? In EasyAnt, we currently don't want to have a prefix separator, by conventions our public target are prefixed with : and our private target are prefixed with -. Thanks in advance for your feedback. 2008/11/11 Stefan Bodewig [EMAIL PROTECTED] On 2008-11-10, Stefan Bodewig [EMAIL PROTECTED] wrote: Right now I'm pretty close to simply add an as attribute to import, add include as an alias name for import and make the task behave differently when it is called as include. Done. The implementation differs from EasyAnt's and we don't have phases (yet?), so Jean-Lousi or Xavier should either modify the patch or tell people to now use Ant trunk more recent than 713006. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: EasyAnt use/extends vs import
Maybe this should be done with a additional attribute like :
- ignorePrefix
- disablePrefix
something like
import file=... disablePrefix=true/
WDYT?
2008/11/12 Jean-Louis BOUDART [EMAIL PROTECTED]
Ooops my bad, i've merged with my previous patch :$
This is now fixed in:
http://easyant.abrm.info/trac/browser/trunk/src/main/patches/ant-713373-easyant-patch.diff
The patch contains only things related to phases concept.
In addition to this, i think that we should add a way to disable prefixing,
i have a use case in easyant where i don't want to use prefix.
In the patch i removed this control:
if (configuredValue != null configuredValue.length() == 0) {
configuredValue = null;
}
This allow me to have a dirty fix to import a build script without prefix
:) by setting as attribute to an empty string (import file=... as=/).
2008/11/12 Stefan Bodewig [EMAIL PROTECTED]
On 2008-11-12, Jean-Louis BOUDART [EMAIL PROTECTED] wrote:
EasyAnt switched to ant-713373
Every things seems ok, except prefix separator should be applied on
targets
(ie. in targetHelper) too.
http://easyant.abrm.info/trac/browser/trunk/src/main/patches/ant-713373-easyant-patch.diff
Both places where your patch replaces . with prefixSeparator (line
861 and line 888 of the original) are correct in svn, you must be
using some inconsistent state since your patch won't apply.
I'm a bit puzzled since I never committed a version that had
prefixSeparator only in one place but not the other two.
Stefan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: EasyAnt use/extends vs import
Ooops i forgot ignoring prefix should ignore also prefix separator
2008/11/12 Jean-Louis BOUDART [EMAIL PROTECTED]
Maybe this should be done with a additional attribute like :
- ignorePrefix
- disablePrefix
something like
import file=... disablePrefix=true/
WDYT?
2008/11/12 Jean-Louis BOUDART [EMAIL PROTECTED]
Ooops my bad, i've merged with my previous patch :$
This is now fixed in:
http://easyant.abrm.info/trac/browser/trunk/src/main/patches/ant-713373-easyant-patch.diff
The patch contains only things related to phases concept.
In addition to this, i think that we should add a way to disable
prefixing, i have a use case in easyant where i don't want to use prefix.
In the patch i removed this control:
if (configuredValue != null configuredValue.length() == 0) {
configuredValue = null;
}
This allow me to have a dirty fix to import a build script without prefix
:) by setting as attribute to an empty string (import file=... as=/).
2008/11/12 Stefan Bodewig [EMAIL PROTECTED]
On 2008-11-12, Jean-Louis BOUDART [EMAIL PROTECTED] wrote:
EasyAnt switched to ant-713373
Every things seems ok, except prefix separator should be applied on
targets
(ie. in targetHelper) too.
http://easyant.abrm.info/trac/browser/trunk/src/main/patches/ant-713373-easyant-patch.diff
Both places where your patch replaces . with prefixSeparator (line
861 and line 888 of the original) are correct in svn, you must be
using some inconsistent state since your patch won't apply.
I'm a bit puzzled since I never committed a version that had
prefixSeparator only in one place but not the other two.
Stefan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: EasyAnt use/extends vs import
I'm using import, but it seems that aliases are also applied on import i thought it was what you were excepecting. In our first patch import was'nt prefixed. I'll try to give you details project name=userBuild import file=build-std-java/ /project project name=org.apache.easyant#build-std-java import file=phase/ include file=compile-java as=compile/ ... include file=whatever asmyPrefix/ /project project name=org.apache.easyant#compile-java target name=iLikeToCompileJavaClasses description=i like to compile java classes :)/ /project project name=org.apache.easyant#whatever target name=plop description=foo bar/ /project by typing ant -p i can see org.apache.easyant#build-std-java.compile.iLikeToCompileJavaClasses -- i like to compile java classes :) org.apache.easyant#build-std-java.myPrefix.plop -- foo bar As you can see it seems that even using import without as attribute, it seems that my import has been prefixed with ant project name. In my case i want to see build-std-java target as if it was my current build script (ie without prefix) : compile.iLikeToCompileJavaClasses -- i like to compile java classes :) myPrefix.plop -- foo bar 2008/11/13 Stefan Bodewig [EMAIL PROTECTED] On 2008-11-12, Jean-Louis BOUDART [EMAIL PROTECTED] wrote: In addition to this, i think that we should add a way to disable prefixing, i have a use case in easyant where i don't want to use prefix. Why don't you use import instead of include in that case? Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: EasyAnt use/extends vs import
It seems to be related to this test
if (!isInIncludeMode context.isIgnoringProjectTag()
means ProjectHelper is currently importing a file
(prefix = getTargetPrefix(context)) != null
and there is a prefix defined for the imported file (either an
explicit as prefix or the imported project's name attribute)
Here it is i'm importing a file that has no explicit as prefix.
So calling to (prefix = getTargetPrefix(context)) will return the imported
project's name.
That's why i'm entering into the body of this test
!isPhase) {
Don't know how phase is supposed to factor into this.
The body of that expression adds a prefixed target in addition to the
non-prefixed target
Adding yet another condition should make the body get executed less
often, so I don't see why you should get a prefix if you make the body
less likely to be executed.
Is there a similar additional condition to the place where the
unprefixed targets are added?
Nop :'(
http://easyant.abrm.info/trac/browser/trunk/src/main/patches/ant-713373-easyant-patch.diff
Re: EasyAnt use/extends vs import
Refering to the comment
// In an imported file (and not completely ignoring the project tag
*OR*having a preconfigured prefix)
this test should be like this instead
if (!isInIncludeMode !isPhase (context.isIgnoringProjectTag()
|| (prefix = getTargetPrefix(context)) != null)) {
Maybe i'm getting wrong
2008/11/13 Jean-Louis BOUDART [EMAIL PROTECTED]
It seems to be related to this test
if (!isInIncludeMode context.isIgnoringProjectTag()
(prefix = getTargetPrefix(context)) != null !isPhase)
{
But i don't understand why yet :(
Any idea?
2008/11/13 Stefan Bodewig [EMAIL PROTECTED]
On 2008-11-13, Jean-Louis BOUDART [EMAIL PROTECTED] wrote:
I'll try to give you details
[snip - removed import phase since you didn't give the file]
by typing ant -p i can see
org.apache.easyant#build-std-java.compile.iLikeToCompileJavaClasses --
i
like to compile java classes :)
org.apache.easyant#build-std-java.myPrefix.plop -- foo bar
This is what I get with Ant trunk:
$ ./build.sh -f ../../Temp/u.xml -p
Buildfile: c:\Temp\u.xml
Main targets:
compile.iLikeToCompileJavaClasses i like to compile java classes :)
myPrefix.plop foo bar
This seems to be what you want, I just don't understand why your
result may be different. Could you please do a diff between your
ImportTask and ProjectHelper2 and Ant's svn trunk? You must have
missed/modified some part of trunk that is not related to phases.
Stefan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: EasyAnt use/extends vs import
by typing ant -p i can see
org.apache.easyant#build-std-java.compile.iLikeToCompileJavaClasses --
i
like to compile java classes :)
org.apache.easyant#build-std-java.myPrefix.plop -- foo bar
This is what I get with Ant trunk:
$ ./build.sh -f ../../Temp/u.xml -p
Buildfile: c:\Temp\u.xml
Main targets:
compile.iLikeToCompileJavaClasses i like to compile java classes :)
myPrefix.plop foo bar
unless I add an empty target to build-std-java in front of the
includes. If I do, I get the same prefixed names that you get.
ok :)
So what is the expected behavior for prefix nesting?
From my reading of what you expect it should be
* import import doesn't contribute to the prefix of included files
at all
except if we explicitly give an as attribute for import
* includes stack up to make a longer prefix
Is this independent of whether the as asstribute (for either of the
tasks) has been specified?
Is there some rationale that makes the rules easy to memorize and
document?
While using nested include, stack up to make a longer prefix (the value of
the as attribute or the imported project's name attribute, if any).
import doesn't contribute to the prefix of included files at all except
if we explicitly give an as attribute for import.
If my assumptions are correct then
private String getTargetPrefix(AntXMLContext context) {
String configuredValue = getCurrentTargetPrefix();
if (configuredValue != null configuredValue.length() == 0) {
configuredValue = null;
}
if (configuredValue != null) {
return configuredValue;
}
String projectName = context.getCurrentProjectName();
if (.equals(projectName)) {
projectName = null;
}
+ if (context.isIgnoringProjectTag() isInIncludeMode()) {
// help nested include tasks
if (projectName != null) {
setCurrentTargetPrefix(projectName);
}
+ }
return projectName;
should help your caae. It isn's a complete fix since the prefix for
included files without as doesn't get set before the first target
(if any) is encountered.
Seems to work, thanks
Re: EasyAnt use/extends vs import
Swich done, everything works perfectly I like how you've documented it :) I've updated the patch (now it contains only phases features) http://easyant.abrm.info/trac/browser/trunk/src/main/patches/ant-713748-easyant-patch.diff Thanks again for this integration 2008/11/13 Stefan Bodewig [EMAIL PROTECTED] should help your caae. It isn's a complete fix since the prefix for included files without as doesn't get set before the first target (if any) is encountered. The complete fix should be revision 713745. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: EasyAnt phases
Here is some additional information on EasyAnt phase concept http://easyant.abrm.info/trac/wiki/tasks/phase
Re: EasyAnt phases
So any conclusions? Does this feature should be integrated to ant-core? or prove it's usefulness in EasyAnt move it into core later if it truly proves useful ? 2008/11/14 Dominique Devienne [EMAIL PROTECTED] On Fri, Nov 14, 2008 at 7:55 AM, Stefan Bodewig [EMAIL PROTECTED] wrote: On 2008-11-13, Dominique Devienne [EMAIL PROTECTED] wrote: This would be cleanly solved by the proto shown once a long time ago by Conor (I believe), where dependencies could be specified *inside* the target body. https://issues.apache.org/bugzilla/show_bug.cgi?id=12292 opened by Nicola Ken six years ago, with patch. Man, you're good :) I remembered the idea came from one of the Ant2 protos, but not that Nicola Ken actually implemented it. I guess if it didn't fly then, it won't fly now tough. I'm actually having trouble wrapping my head around all the ramifications this would open, when I try to sort it out a bit more ;) --DD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: EasyAnt phases
Sorry i'm missed this mail 2008/11/14 Gilles Scokart [EMAIL PROTECTED] 2008/11/13 Gilles Scokart [EMAIL PROTECTED]: I'm +1 to put the concept in Ant's core, marked as experimental. A question that I have is how deep we want to push this concept? A first level would be that a phase or a target-group is a normal tartget for which the depends is build based on the other target that are found. (with that view, I wonder by the way what motivate the fact that the phase have no tasks). IMHO target-group are more powerfull when depending on other target-groups. I think this kind of target should stay as abstract as possible. This allow you more flexibilty. A second level (maybe I go too far) might be to put it deeper up to the event notification. A build that use phase might have phaseStarted and phaseFinished event sent around targetStarted and targetFinished. This could be interresting A third level (or 2bis) : what will be the meaning if the if/unless attribute on a phase ? With the simple aproach in which phase are 'simple' targets, it does nothing. But I think it would be more intuitice if that would mean do or skip all the target bound in that phase. As target-group is nothing more than a target so if/unless attribute is supported. Exemple project target-group name=test depends=other-targetgroup description=... unless=skip.test/ target name=myTestTarget depends=whatever phase=test ... /target /project By typing ant test you will execute ALL target related to test target-group By typing ant test -Dskip.test=true you will not execute any target related to test target-group. In opposite, if you wanna execute explicitly ant myTestTarget, phase attribute is ignored (so skip.attribute should not be applied). Jean Louis
Re: EasyAnt phases
By typing ant test -Dskip.test=true you will not execute any target related to test target-group. Hmmm, I thought a target group basically had it's depends attribute basically rewritten to include whatever target declared itself to be part of this group, and since if/unless apply to the target's body and not its dependencies, if/unless would have been useless on target-groups. So either I assumed incorrectly how target-group was implemented, or what you describe above (assuming depends attribute re-writing) is incorrect. So which is it? *hides* My bad, i merged two different things in my answer :) Currently if /unless attribute is ignored on target-group. But it could be interresting feature (not yet implemented) to support that attribute to skip all task related to a given phase
Re: target-group committed
svn revision 718943 contains target-group (without documentation) as a special kind of target that must always be empty. targets and target-groups have a new attribute target-group that can be used to add the target(-group) to a named target-group that must have been defined already[1]. Maybe this should be a comma-separeted list of traget-groups to add to instead. Dependenices are always appended. Nice ! I think I got the naming conventions of include right, but there will be some import scenarios that haven't been covered (like the imporitng build file naming a plain target the same as an imported target-group). I just have two questions : - Does prefix of import / include make sense on target-group? Or should we consider target-group as an abstract target that is never prefixed? - When displaying projecthelp should we have target and target-group mixed? or should we have a distinction? Exemple : project name=org.apache.ant#jar target name=compile-java target-group=compile description=compile java classes on the current project /target target name=package-jar target-group=package description=package this project as a jar /target /project project name=generic target-group name=compile description=compile the current projet/ target-group name=package description=package the current project depends=compile/ include file=/path/to/jar.xml as=jar / /project By typing ant -p 1) Case of target and target-group mixed project help will display something like :*Available target :* compile -- compile the current projet compile-java -- compile java classes on the current project package -- package the current project package-jar -- package this project as a jar 2) Case when target and target-group are separated *Available target-group :* compile-java -- compile java classes on the current project package-jar -- package this project as a jar *Available target :* compile -- compile the current projet package -- package the current project Regards Jean Louis
Re: target-group committed
Hum little mistake in my explanation : By typing ant -p 1) Case of target and target-group mixed project help will display something like :*Available target :* compile -- compile the current projet org.apache.ant#jar.compile-java -- compile java classes on the current project package -- package the current project org.apache.ant#jar.package-jar -- package this project as a jar 2) Case when target and target-group are separated *Available target-group :* compile-java -- compile java classes on the current project package-jar -- package this project as a jar *Available target :* compile -- compile the current projet package -- package the current project 2008/11/19 Jean-Louis BOUDART [EMAIL PROTECTED] svn revision 718943 contains target-group (without documentation) as a special kind of target that must always be empty. targets and target-groups have a new attribute target-group that can be used to add the target(-group) to a named target-group that must have been defined already[1]. Maybe this should be a comma-separeted list of traget-groups to add to instead. Dependenices are always appended. Nice ! I think I got the naming conventions of include right, but there will be some import scenarios that haven't been covered (like the imporitng build file naming a plain target the same as an imported target-group). I just have two questions : - Does prefix of import / include make sense on target-group? Or should we consider target-group as an abstract target that is never prefixed? - When displaying projecthelp should we have target and target-group mixed? or should we have a distinction? Exemple : project name=org.apache.ant#jar target name=compile-java target-group=compile description=compile java classes on the current project /target target name=package-jar target-group=package description=package this project as a jar /target /project project name=generic target-group name=compile description=compile the current projet/ target-group name=package description=package the current project depends=compile/ include file=/path/to/jar.xml as=jar / /project By typing ant -p 1) Case of target and target-group mixed project help will display something like :*Available target :* compile -- compile the current projet compile-java -- compile java classes on the current project package -- package the current project package-jar -- package this project as a jar 2) Case when target and target-group are separated *Available target-group :* compile-java -- compile java classes on the current project package-jar -- package this project as a jar *Available target :* compile -- compile the current projet package -- package the current project Regards Jean Louis
Re: target-group committed
I agree with Xavier a target-group is something at a higher level than a target. I think that the key feature of target-group is dependency injection but as Xavier says if thread-group is the only way to have target dependency injection, then people may use it only for that, and complain about the distinction in project help. The fact is target-group is not only a way to have dependency management, but a new way to think your build-script. I guess for us target-group is useful to make build modules easily reusable in a standard build (with standard target-group), without requiring any specific orchestration. This means target-group allow you to have a kind of generic target, that's why in EasyAnt we want to have separated help for generic targets (target-group) and specific target (normal target). In addition, as we use target-group to have more genericity we doesn't want to have prefix on those generic targets.
Re: target-group committed
I think this is a typo he wanted to say target-group IMHO :p 2008/11/20 Stefan Bodewig [EMAIL PROTECTED] On 2008-11-20, Xavier Hanin [EMAIL PROTECTED] wrote: I'm not sure if it's directly related to thread-group, or to the usage made of thread-group in EasyAnt: could you please explain what a thread-group in EasyAnt is/does? Thanks Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: target-group committed
The fact is target-group is not only a way to have dependency management, but a new way to think your build-script. Yes, but only for the person who writes the build file, not the one who uses it. -projecthelp is for the user. I guess for us target-group is useful to make build modules easily reusable in a standard build (with standard target-group), without requiring any specific orchestration. This means target-group allow you to have a kind of generic target, that's why in EasyAnt we want to have separated help for generic targets (target-group) and specific target (normal target). Why would the user care whether she invokes a generic or specific target? Suppose you have a build with 10 target-group which represent 10 different generic step of your build process (like compile / package/ test/ etc...) And behind you have 30 submodules that have one or many target associated (or not) to that target-groups (compile-java,compile-scala,compile-whatever,javadoc,etc) As target-group are top-level target, as a user i would prefer to see target-group separated instead of having to lookup at ALL target available. In the case where target and target-group are mixed how would you (as a user) make the difference of what is a TOP level target (ie a generic task) and a specific target? I guess usign ant compile has MORE consequences than using ant compile-java. Maybe my example is not enough revelent :'( Here is a short example of EasyAnt project help : Main phases: compile compile the source code of the project generate-resources generate resources for inclusion in the package generate-sourcesgenerate any source code for inclusion in compilation integration-testprocess and deploy the package if necessary into an environment where integration tests can be run package take the compiled code and package it in its distributable format, such as a JAR. post-integration-test perform actions required after integration tests have been executed. This may including cleaning up the environment pre-integration-testperform actions required before integration tests are executed. This may involve things such as setting up the required environment prepare-package perform any operations necessary to prepare a package before the actual packaging. This often results in an unpacked, processed version of the package process-classes post-process the generated files from compilation, for example to do bytecode enhancement on Java classes process-resources copy and process the resources into the destination directory, ready for packaging process-sources process the source code, for example to filter any values provision supply provision required by this project publish-local publish the package into the local repository, for use as a dependency in other projects locally publish-shared done in an integration environment, copies the final package to the remote repository for sharing with other developers and projects release done in an integration or release environment, copies the final package to the remote repository for sharing with other developers and projects report generate report testrun tests using a suitable unit testing framework. These tests should not require the code be packaged or deployed test-compilecompile the test source code into the test destination directory test-generate-resources create resources for testing test-generate-sources generate any test source code for inclusion in compilation test-process-resources copy and process the resources into the test destination directory test-process-sourcesprocess the test source code, for example to filter any values test-provision supply provision required to test this project validatevalidate the project is correct and all necessary information is available verify run any checks to verify the package is valid and meets quality criteria Main targets: checkstyle:checkstyle generate checkstyle report clean:clean clean project doc:documentation generate documentation emma:emma generate emma covera report jar:jar package project as a JAR javadoc:javadoc generate javadoc report for main classes and test classes lib-resolve resolve and retrieve dependencies with ivy lib:common-ivy:clean-cache clean the ivy cache lib:common-ivy:clean-libclean the project libraries directory lib:common-ivy:report generate dependencies report publish:clean-local cleans the local repository run:run run the application source:main package main source
Re: Yet an other view for target-group
Which from the end-user POV means targets and target-groups are command line callable, target-parts are not. Is that correct? Stefan I would prefer that they could be called. I think both target and target group should be command line callable. I actually see a very big difference for the user running Ant. A target-group has an higher granularity. A normal user would rather use that granularity level. Only advanced users (probably the developpers who wrote the script) could still call lower level part. I completly aggree :) I would say that target-group, target-part are different level of abstraction. What part constitues the group are implementation details that should be +/- hidden for the normal user (and probably for developpers of other part of the global script). Maybe an other way to see the difference is to foccus on the relationship PartOf, instead of foccussing on the distinction target-group, target-part. I think it is easier to see a difference beween PartOf and Depends relationship. I think it's pretty much easier to see the difference like that :) I'm not sure I clarified something... I hope I didn't add more confusion ;-) I hope so :p
Re: target-group committed
I'm +1 for this solution 2008/11/26 Dominique Devienne [EMAIL PROTECTED] On Wed, Nov 26, 2008 at 2:06 PM, Bruce Atherton [EMAIL PROTECTED] wrote: Or you could just live with the verbosity of the target list, like I did, and use naming conventions in EasyAnt. I'm sure there are many other ways to address the issue. One possible way would be to provide an in-build-file hook to intercept the -p switch, and this hook (I envision a target) would then be responsible to display the help. Couple that with a new configurable task to generate the -p output, and then it's up to the user to select (via some kind of include/exclude) whatever targets are going to be listed. My builds used to all have a help target which java'd back into Ant on the same build file with the -p switch added. It's the same idea, but exposing a builtin task instead, and allowing to run that target when -p is specified, if it's hooked via for example a project help-target=help. --DD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: target-group committed
Any news on this point? 2008/11/24 Xavier Hanin [EMAIL PROTECTED] On Fri, Nov 21, 2008 at 12:26 AM, Jean-Louis BOUDART [EMAIL PROTECTED] wrote: In addition, as we use target-group to have more genericity we doesn't want to have prefix on those generic targets. I'm afraid I don't understand this. One of your selling points for include was that the included build is self-contained and remains that way by prefixing all traget names and rewriting the depends lists. If we break that rule for some kind of target, the included build is suddenly open for modifications from the outside - including overrides of target-groups. Again if we consider target-group as JUST a way to have target dependency injection, this doesn't make sens. In opposite if we consider that target-groups are toplevel target does't it make sens to have prefix on target-group? Example (using current HEAD revision): Suppose you want to have a generic task called report a.xml project name=A target name=javadoc target-group=report description=generate javadoc echojavadoc/echo /target ... /project b.xml project name=B target name=junitreport target-group=report description=generate junit report echojunitreport/echo /target ... /project c.xml project name=C target name=emma-report description=generate emma report target-group=report echo emma report/echo /target ... /project phases.xml project name=phases target-group name=report description=generate all report for your project / /project build.xml project name=generic-build import file=phase.xml/ include file=a.xml as=javadoc/ include file=b.xml as=junit/ include file=c.xml as=emma/ /project If you try to use ant report : you have this message can't add target javadoc.javadoc to target-group javadoc.report because the target-group is unknown. IMHO a target-group should NEVER be prefixed, in a module it's possible to assign a target to a phase which is not declared in the build module. It makes the module dependent on the caller to declare the phase prior to the use call, and as such becomes a requirement of the module. I would like to bring more attention to this, because I think Jean-Louis makes a very good point here. IMO joining a target group for a target should be possible for a target group which is defined in a build file including the build file in which the target itself is defined. So maybe name resolution of a target-group when a target declares to join a target-group (with target name=foo target-group=bar /) in an included file should first look for the prefixed name (as it is currently implemented) and then if it doesn't exist, try to look for the non prefixed name. WDYT? -- Xavier Hanin - 4SH France BordeauxJUG co leader - http://www.bordeauxjug.org/ Blogger - http://xhab.blogspot.com/ Apache Ivy Creator - http://ant.apache.org/ivy/
EasyAnt 0.4 beta 1 Release
The EasyAnt project is pleased to announce its 0.4-beta-1 version. Easyant is a toolbox focusing on easing project build processes. It's based on Apache Ant and Apache Ivy, and allows for maximum flexibily, improved integration in existing build systems and provides conventions and guidelines. This version focus on : - multi project support ( related to https://issues.apache.org/jira/browse/IVY-742 ) - a first version of Easyant Module Documentation generation (refer to http://easyant.abrm.info/trac/ticket/9 ). - a documentation module a la XDoc - a source module (that allow you to create a package containing project sources) - support of file attribute in property tag in module ivy (ie. allow us to use a syntax similar to the ant one property file=myPropertyFile/) - refactoring use / extends tasks names to be compliant with ant I would like to thanks ant-dev team (in particular Stefan Bodewig) for their interest on EasyAnt. use / extends concept is now integrated in ant-core This concept is related to import mechanism in ant. What we call use has been renamed in include in ant What we call extends is like the current import in ant For recall, as the project is still in an early phase, easyant plugins are still unstable and can move on next releases. Issues should be reported to: http://easyant.abrm.info/trac/ Retrieve sources from the 0.3-beta-1 release files at: http://easyant.abrm.info/svn/tags/easyant-0.4-beta-1 Or download the 0.4-beta-1 release files at: http://easyant.abrm.info/trac/downloader More information can be found on the Easyant website: http://easyant.abrm.info/ Regards, Jean Louis Boudart
EasyAnt 0.5-beta1 released !
The EasyAnt project is pleased to announce its 0.5-beta-1 version. Easyant is a build system, that is based on Apache Ant and Apache Ivy. Our goals are : - to leverage popularity and flexibility of Ant. - to integrate Apache Ivy, such that the build system combines a ready-to-use dependency manager. - to simplify standard build types, such as building web applications, JARs etc, by providing ready to use builds. - to provide conventions and guidelines. - to make plugging-in of fresh functionalities easy as writing simple Ant scripts as Easyant plugins. To still remain adaptable, - Though Easyant comes with a lot of conventions, we never lock you in. - Easyant allows you to easily extend existing modules or create and use your own modules. - Easyant makes migration from Ant very simple. Your legacy Ant scripts could still be leveraged with Easyant. This version focus on : - a module for jetty-deployement - a module for documentation (based on Xooki) - a module for repository management (ie. Install new artifacts / copy artifacts from other repo) - a module allowing a user to create / retrieve skeleton of project - a module and a associated build-type for OSGI bundle creation. - a module providing SVN features (not yet implemented) - a module providing Groovy features (not yet implemented) - documentation / javadoc - a new ant tasks that allow a plugin writer to document with compatible core version for a given plugin - Few enhancement: - A few pattern properties (with default values) to tune what should be included/excluded during Compilation/Packaging etc... - Each modules have a dynamic classpath based on what is included in the plugin dependencies For recall, as the project is still in an early phase, easyant plugins are still unstable and can move on next releases. Issues should be reported to: http://www.easyant.org/trac/ Retrieve sources from the 0.5-beta-1 release files at: http://svn.easyant.org/tags/0.5-beta-1/ Or download the 0.5-beta-1 release files at: http://www.easyant.org/trac/downloads Online documentation is now accessible through : http://www.easyant.org/doc/ More information can be found on the Easyant website: http://www.easyant.org/ Regards, Jean Louis Boudart
A few questions on ant-core
Hi there,
I have a few questions on ant-core.
*How to extends the main class?*
I would like to extends the main class to deal with new command line
parameters for EasyAnt, and have a custom project help.
I must create a new class that implements AntMain interface.
And then ask the lancher to use my implementation using the -main
argument.
Am i right?
If i want to keep part of the current services provided by the default ant
main class i would probably extends Main class.
But part the most interresting methods that i want to override seems to be
private (see processArgs for example).
Is there any reason for?
Should i write my own inspired from the default one?
*How to customize ProjectHelper?*
Getting back to our previous discution about Phases vs target group, it
seems that there is a special case in easyant where we don't want to have
prefixed phases from an imported build script.
So maybe the solution is to keep phase context only in easyant and find a
proper way to implement it rather than a patch :).
As the prefix job is done by ProjectHelper i think i must extends this class
So my question is how could i use a custom ProjectHelper?
*Additional questions *
Dealing with ftp / scm / ssh / whatever we all the time need to deal with
passwords. It will be cool to provide a way to have crypted / obfuscated
property (using md5/sha1 or whatever).
How this could be implemented?
Introducing a new argument on property task to say crypted (example:
property name=plop value=myCryptedValue crypted=true/) ?
Having a specific delimiter (example : property name=plop
value={myCryptedValue}/ everything within the brackets is crypted).
And the the most important question how to read (uncrypt) this property?
Extending PropertySetter / PropertyEvaluator / PropertyExpander ?
Any ideas?
Thanks in advance
Jean Louis Boudart
Re: A few questions on ant-core
No ideas? :'(
2009/4/6 Jean-Louis BOUDART jeanlouis.boud...@gmail.com
Hi there,
I have a few questions on ant-core.
*How to extends the main class?*
I would like to extends the main class to deal with new command line
parameters for EasyAnt, and have a custom project help.
I must create a new class that implements AntMain interface.
And then ask the lancher to use my implementation using the -main
argument.
Am i right?
If i want to keep part of the current services provided by the default ant
main class i would probably extends Main class.
But part the most interresting methods that i want to override seems to be
private (see processArgs for example).
Is there any reason for?
Should i write my own inspired from the default one?
*How to customize ProjectHelper?*
Getting back to our previous discution about Phases vs target group, it
seems that there is a special case in easyant where we don't want to have
prefixed phases from an imported build script.
So maybe the solution is to keep phase context only in easyant and find a
proper way to implement it rather than a patch :).
As the prefix job is done by ProjectHelper i think i must extends this
class
So my question is how could i use a custom ProjectHelper?
*Additional questions *
Dealing with ftp / scm / ssh / whatever we all the time need to deal with
passwords. It will be cool to provide a way to have crypted / obfuscated
property (using md5/sha1 or whatever).
How this could be implemented?
Introducing a new argument on property task to say crypted (example:
property name=plop value=myCryptedValue crypted=true/) ?
Having a specific delimiter (example : property name=plop
value={myCryptedValue}/ everything within the brackets is crypted).
And the the most important question how to read (uncrypt) this property?
Extending PropertySetter / PropertyEvaluator / PropertyExpander ?
Any ideas?
Thanks in advance
Jean Louis Boudart
Re: distribution of ivy with ant
IMHO Ant and Ivy may be released separately. Each project has his own release process. Release are more common on ivy whereas Ant is released once in one or two years. Does it means that ant will make a whole distribution for each strong enhancements on ivy? I agree Xavier that people may want to update their own ivy version without waiting for an ant distribution. Even if ivy offer a lot of ant tasks its first of all a standalone tool that provide all you need to deal with dependency management. This means ivy was originally made to work outside of any ant context. Considering that it make sense that ivy is and should stay an optionnal ant task. 1. Out-of-the-box support for dependency management for ant 2. Better integration of ivy with ant 3. No more check, download and load ivy targets in build files 4. Lowered entry barrier to using ivy for existing ant users 5. Exposure of ivy to more users I'm totally +1 but i'm not sure Ant is the best place to do that. To have out of the box support you will need to provide some preconfigured targets (that also implies to have conventions) ivysettings.xml and this is not the job of ant. If you are looking for a tool that make a distribution of ant+ivy with conventions / preconfigured targets / preconfigured ivy conf and that is still flexible you should probably look at : - Gradle (http://www.gradle.org) - EasyAnt (http://www.easyant.org). From my point of view those two projects can make the usage of ant+ivy easier. Cheers, Jean Louis Boudart 2009/5/28 Nick Pellow npel...@atlassian.com +1 to shipping Ivy with Ant - maybe even call it Ant 2.0 ? On 28/05/2009, at 2:30 AM, Jason Trump wrote: That is definitely a cool idea. Another possibility would be to use embedded Ivy to implement an auto-update feature for ant and/or ivy itself. Not a three-dialogs-per-day kind of auto-update feature, of course. jason From: Martin Eigenbrodt [mailto:martineigenbr...@googlemail.com] Sent: Wed 5/27/2009 2:02 AM To: Ant Developers List Subject: Re: distribution of ivy with ant I think this is a great Idea and could bring the power of ivy to the core of ant. You could then even change taskdef (or write a similair task) to support somethingh like: taskdef org=cobertura module=cobertura revision=1.9.1 resource=tasks.properties/ No need to manually download the files and setup a path before. This would make using ant extensions/ thirdparty tasks easier. Best regards, Martin 2009/5/27 Xavier Hanin xavier.ha...@gmail.com On Tue, May 26, 2009 at 4:49 PM, Steve Loughran ste...@apache.org wrote: Enis Soztutar wrote: I don't know if it is discussed previously but I was wondering why ivy is not included in the ant distribution. More and more projects previously depending on ant start to use ivy, but the build files are cluttered with ivy-download, check-ivy-antlib, etc. Technically ivy is a subproject of ant, and it can be used optionally. However if they are distributed together there will be several benefits: 1. Out-of-the-box support for dependency management for ant 2. Better integration of ivy with ant 3. No more check, download and load ivy targets in build files 4. Lowered entry barrier to using ivy for existing ant users 5. Exposure of ivy to more users the only drawback I can think of is the extra ivy jar file in the distribution. Is there any plans on the roadmap? Now that ivy is part of Ant, it makes sense to start thinking of bundling the two. However, it may tie the release cycle of the faster moving item (ivy) to that of the slower one. Ivy may still be released separately too, so that people wanting to upgrade their Ivy version without waiting for a release of Ant could still do it. WDYT? Xavier Do you think things have stabilised/slowed down enough for this? We can of course increase the release frequency of Ant... - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org -- Xavier Hanin - 4SH France BordeauxJUG co leader - http://www.bordeauxjug.org/ Blogger - http://xhab.blogspot.com/ Apache Ivy Creator - http://ant.apache.org/ivy/ - 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
EasyAnt 0.6 released !
The EasyAnt project is pleased to announce its 0.6 version. Easyant is a build system, that is based on Apache Ant and Apache Ivy. Our goals are : * to leverage popularity and flexibility of Ant. * to integrate Apache Ivy, such that the build system combines a ready-to-use dependency manager. * to simplify standard build types, such as building web applications, JARs etc, by providing ready to use builds. * to provide conventions and guidelines. * to make plugging-in of fresh functionalities easy as writing simple Ant scripts as Easyant plugins. To still remain adaptable, * Though Easyant comes with a lot of conventions, we never lock you in. * Easyant allows you to easily extend existing modules or create and use your own modules. * Easyant makes migration from Ant very simple. Your legacy Ant scripts could still be leveraged with Easyant. This version focus on : * a better support for multi module projects * adding support to build configurations (similar to profile in maven world see http://easyant.org/doc/howto/BuildConfigurations.html for more details) * a new core offering api that can work in embebbed mode * a cleaner repository structure used to store easyant plugins / build types * introducing a way to skip an entire module * adding support for variables replacements inside module.ivy * a module for antunit test * a module to generate plugin documentation * documentation / javadoc * a few tests to enhance easyant-core stability * several bug fixes on plugins For recall, as the project is still in an early phase, easyant plugins are still unstable and can move on next releases. Issues should be reported to: http://www.easyant.org/trac/ Retrieve sources from the 0.6 release files at: http://svn.easyant.org/tags/0.6/ Or download the 0.6 release files at: http://www.easyant.org/trac/downloads Online documentation is now accessible through : http://www.easyant.org/doc/ More information can be found on the Easyant website: http://www.easyant.org/ Regards, Jean Louis Boudart
Re: A groovy frontend for Ant
Hi, I know Jean-Louis BOUDART has been working on plugging different frontends into EasyAnt so maybe we could join forces - Jean-Louis, are you reading this? Sorry for long responding i was on holidays :). I was thinking a few time ago to introduce an abstraction layer in the project helper. As stefan highlighted ant and subant task are configured through the ProjectHelper that's why i wanted to put the abstraction layer here. Why adding a new abstraction layer ? As everyone knows the only way to write an ant script is XML. It could be really interesting to support others languages like Java or groovy. Then if users want to write their own ant script they are able to write it in XML (with ant syntax has everyone know in the world :)) or in Java (maybe Groovy ? or whatever). I thought about writing a ProjectHelper that will be in charge to determine which dialect will be used (maybe based on conventions on extensions .ant .java .jar .groovy) and to delegate to a class that will be in charge to do all the specific stuff. I didn't get time to start a POC on this but i will do it in the next few days. It could be cool if we could join forces on this. Cheers -- Jean Louis Boudart Independent consultant Project Lead http://www.easyant.org
Querying ant context
Hi there, The new abstraction layer on ProjectHelper is awesome ! But now i'm wondering how can we make (in a generic way) reports for our builds? There were a few existing projects (AntDoc for example) but there were all XML based. What solution could we use to generate such report? I've tried to play with the infos accessible in the Project instance. It seems that we are able to access every task used/defined in a target (using the method getTasks() on Target.java). Here we can have a lot of infos. However it seems that we're not able to access all tasks defined outside of the target. A quick example: project import file=myfile/ myTask/ target name=foobar thisTaskCanBeDocumentedBecauseWeAreInsideATarget/ /target /project Here we're not able to know the task defined outside the target (import, myTask in the previous example). All this tasks seems to be attached to a virtual target (a target without name) referenced by the XMLContext instance which is all the time overwritten during import. Did i miss something? Any idea of how this could be done? Thanks for you help. -- Jean Louis Boudart Independent consultant Project Lead http://www.easyant.org
Re: [VOTE] name for target-group
[ x] extension-point name=foo/ for the group and target extensionOf=foo ... for members of the group or as an alternative [ x] target-interface name=foo/ for the group and target implements=foo ... for the members of the group 2009/12/22 Antoine Levy Lambert anto...@gmx.de Antoine Levy Lambert wrote: [ x] target-group name=foo/ for the group and target group=foo ... for the members of the group this is the current codebase Let me start with +1 for the current codebase. Antoine - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org -- Jean Louis Boudart Independent consultant Project Lead http://www.easyant.org
Re: Maybe we should open up depends for all targets [again]
You're right. Initially in EasyAnt we wanted to find a way to define lifecycles. A lifecycle is composed by a sequence of generic steps (what we've called phase). Then we could play with additional script (plugins) that can be bind to a phase. Again the idea was to make genericity in our build scripts. So suppose we have a target that does the java-compilation (bind to compile phase), another one that does the jar-packaging (bind to package phase) etc... Now suppose we want to build a webapp the only thing that will differ with my previous exemple is the target that package the war (which can be bind to package phase). As a end user we will still have the common lifecycle with all our steps (phase) like compile, package etc... in any context (standar java application, webapp etc...) Since our use case was really similar with maven phases we decided to use the same name. Now i think it can be limitting to integrate it in ant with that name(phase), that's why when this feature was introduced in ant's trunk, someone suggested to call it target-group. By the way there is still a main difference between a target-group and a phase. A phase is never prefixed whereas a target-group can be prefixed depending on how you import/include it. Again if we consider target-group is JUST a way to have target dependency injection, this doesn't make sense. In opposite if we consider that target-groups are toplevel target(to define a lifecycle for exemple), does't it make sens to have prefix on target-group? Example (using current HEAD revision): Suppose you want to have a generic task called report a.xml project name=A target name=javadoc target-group=report description=generate javadoc echojavadoc/echo /target ... /project b.xml project name=B target name=junitreport target-group=report description=generate junit report echojunitreport/echo /target ... /project c.xml project name=C target name=emma-report description=generate emma report target-group=report echo emma report/echo /target ... /project phases.xml (containing our lifecycle) project name=phases target-group name=report description=generate all report for your project / /project build.xml project name=generic-build import file=phase.xml/ include file=a.xml as=javadoc/ include file=b.xml as=junit/ include file=c.xml as=emma/ /project If you try to use ant report : you have this message can't add target javadoc.javadoc to target-group javadoc.report because the target-group is unknown. Using phase (a target-group never prefixed), it is possible in a buildscript to assign a target to a phase which is not declared in the current build script. It makes the buildscript dependent on the caller to declare the phase prior to the use call, and as such becomes a requirement of the buildscript. Considering that this was a use case really related to easyant, we've made our own implementation of phase inspired by target-group current code base. This means we have our own ProjectHelper so we will not be really affected by any change the naming of target-group. Hope this will help the discution. Cheers, Le 16 décembre 2009 14:12, Nicolas Lalevée nicolas.lale...@hibnet.org a écrit : On Sat, 12 Dec 2009 13:03:45 +0100, Jean-Louis Boudart jeanlouis.boud...@gmail.com wrote: How about: target-inteface name=foo/ target name=bar implements=foo/ /me run and hides! 2009/12/12 Nicolas Lalevée nicolas.lale...@hibnet.org On Fri, 11 Dec 2009 11:51:30 -0600, Dominique Devienne ddevie...@gmail.com wrote: On Fri, Dec 11, 2009 at 6:32 AM, Xavier Hanin xavier.ha...@gmail.com wrote: 2009/12/10 Stefan Bodewig bode...@apache.org and would do away with any notion of target composition people way expect from the name target-*group*. I also think the name target-group is confusing for something that doesn't provide any composition. [...] What do you think this: target name=foo dependencies=open/ target name=bar join-depends=foo/ Like in a SQL join you mean? ;) But I'm not good at finding names, so maybe I should just go back to my work :-) Frankly I think the Maven terminology of a goal is appropriate here. The fact that a goal is implemented as a target that has no tasks is an impl detail. I think it easier that a goal is a higher level abstraction that the target, and that target can choose to participate into one and only one goal. Whether goals themselves should only depend on goals might be a good idea. Goals would define the abstract interface to the build system and logic, and targets become its implementation. As I wrote, a target can belong to only a single goal, but can depend on targets or goals, as long as the DAG is acyclic. I think that abstract interface target and implementation target seems to fit very well into my use case I presented earlier. It was about a build script expecting some target implementation to be run before some other; expecting
EasyAnt 0.7 Released !
The EasyAnt http://easyant.org/trac/wiki/EasyAnt project is pleased to announce its 0.7 version. Easyant is a build system, that is based on Apache Ant and Apache Ivy. Our goals are : - to leverage popularity and flexibility of Ant. - to integrate Apache Ivy, such that the build system combines a ready-to-use dependency manager. - to simplify standard build types, such as building web applications, JARs etc, by providing ready to use builds. - to provide conventions and guidelines. - to make plugging-in of fresh functionalities easy as writing simple Ant scripts as Easyant plugins. To still remain adaptable, - Though Easyant comes with a lot of conventions, we never lock you in. - Easyant allows you to easily extend existing modules or create and use your own modules. - Easyant makes migration from Ant very simple. Your legacy Ant scripts could still be leveraged with Easyant. What's new in 0.7? - use latest official ant (no more a patched version) - refactor antcontrib usage, antcontrib is now considered as a dependency of easyant-core - add the capabilty to override target/phases defined in module.ivy (override.module.ant) - enhanced multimodule support - full support for all standard build phases - full support for Ivy descriptor extends - build-scoped repository should allow overwrites (#74) - meta-build: better support for custom ivysettings.xml (#75) - use two cache instance (one for easyant plugins/buildtypes, one for project) - use cache by default instead of retrieving in lib directory - simplify version management : uses revision attribute in module.ivy instead of a specific property (#81) - simplify syntax of easyant tags, plugins/buildtypes now support two ways to be imported (#84): - using mrid plugin mrid=org.apache.easyant.plugins#run-java;0.1/ - using exploded style plugin org=org.apache.easyant.plugins module=run-java revision=0.1/ - support Shortcut on buildtypes / plugins / skeletons in mrid style (#73) - make the help more helpful (#13) introduce new useful command line lines switches (listTargets, listPlugins, listPhases, listProps, describe) - add validation on easyant config files - refactor the repository structure : default plugins/buildtypes are now shipped in easyant-core.jar, additional plugins are now shipped in easyant-extra-plugins.jar (#80) - add support for provided artifacts (#83) - performance improvement - javadoc/scaladoc are no more imported in default buildtypes - enhanced clean cache mechanism (can now clean easyant-cache or project cache) (#79, #80) - add default skeleton for : - standard java application - standard java webapplication - add new plugins - a small webstart plugins (Thanks to Nicolas Gapaillard for the contrib !) - docbook plugin (#62) - cobertura coverage plugin / abstract-coverage support (#67) - a new build type for easyant plugin (simplify easyant plugin development) #85 - improve skeleton plugin (#86) - add support for LICENSE/NOTICE files in package-jar / package-war plugins (#87) - support executable jar attributes in manifest plugin (#76) - several bugfix on - emma - cobertura - junit (#78) - javadoc (#77) - xooki / eadoc The plugin code has become stable, but you can still expect changes before the final release. Issues should be reported to: http://www.easyant.org/trac/ Retrieve sources from the 0.7 release files at: http://svn.easyant.org/tags/0.7/ Or download the 0.7 release files at: http://www.easyant.org/trac/downloads Online documentation is now accessible through : http://www.easyant.org/doc/ More information can be found on the Easyant website: http://www.easyant.org/ Regards, Jean Louis Boudart -- Jean Louis Boudart Independent consultant Project Lead http://www.easyant.org
Re: task that allows augmentation of previously declared references
Sorry for the delay. I really like the idea of being able to augment previously declared reference. There is many uses cases where it can be useful. For example, if ant can provides such feature it would simplify a lot the job in easyant for projects using many directories as source folder. They will just need to augment the fileset used for source folder. It makes also senses for other dataType. I'm also +1 for the final=false attribute. By the way i think the only use case that is discutable is for path. Most of the time we want to append something to an existing classpath, so here augment make sense. But how will the augment feature will help us if we want to prepend things in the classpath (for example if we use coverage tools, instrumented classes must be put before the compiled classes in the classpath)? In EasyAnt we've defined our own path task that handle this use cases (allowing prepend / append / overwrite). Considering that this problem cannot be solved just by using augment feature, should we improve the behavior of path task? or let each projects defined their own task to do this? Is the augment feature already commited on trunk (i've not checked the trunk for a while)? Is it targeted to be in the 1.8.1? My 2 cents 2010/2/25 Dominique Devienne ddevie...@gmail.com On Thu, Feb 25, 2010 at 10:00 AM, Gilles Scokart gscok...@gmail.com wrote: Did you have any example to demonstrates the benefits of such task ? The benefits with conjunction with import could be important, in that you can mix-in specialized pre-defined builds dealing with specific concerns (like JAXB pre-compilation for example) and have those builds implicitly augment the classpath or Javac source path appropriately for example (as documented in those builds, and you do explicitly import those, so are kinda in control). Sure, it does open the door for some complexity, and Ant would enter some un-chartered waters indeed, but when trying to design reusable builds in the (distant now) past, I've often felt the need for such a feature. Yet it doesn't necessarily mean that would have been the right solution either. I'd be interesting to have the input of the EasyAnt people on the matter in fact. Maybe an opt-in approach, explicitly adding final=false on those datatype ids *designed* for extension, would be a more conservative introduction of this feature, although that does force to have perfect hindsight into what will be necessary to extend/augment or not. --DD - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org -- Jean Louis Boudart Independent consultant Project Lead http://www.easyant.org
Augment feature
I think the idea of implementing an augment features (idea initiated by Matt Benson as described https://issues.apache.org/bugzilla/show_bug.cgi?id=48798or in the previous thread) make sense. This idea was to provide a task that allows augmentation of previously declared references. There is many places where it can be useful, and as far as i know nobody was opposed on the main idea. By the way there was one point still in discussion lost in the whole thread. Many person was in favor of an opt-in approach to keep backward compatibility. I guess, you can only use augment feature on references that as been designed for extention (by adding an argument like final=false on the reference for example). Antoine Levy Lamber was highlighting that ant datatypes are currently de-facto mutable by default. And maybe we were complexifying too much this feature. The objective of this thread is to take a decision on : - restriction on augment feature - and if the vote is in favor to choose one implementation design to do it So, What's your opinion ? Should we introduce kind of restriction on the augment feature (like final=false) ? Or should we keep this usable on ALL existing reference ? If the answer is yes How would you like to we restrict this ? - by adding a new attribute (like final=false) on datatype ? - by adding magic properties ? - taking in consideration that taks and types are java objects, can we reuse a java property final as a configuration attribute? Exemple:private final String myProperty; - with another alternative ? IMHO the augment feature can live without any restriction. As highlighted by Antoine, with current code base reference can be modified by user developed ant tasks or script fragments. But, it could make sense to provide a way to make reference unmutable. Doing this a given reference cannot be modified by augment task (or by any user developped ant task / script fragment). For example : - if you design a target (or a datatype) used in a multithread context you probably don't want to make it extensible (because it's gonna be a hell to maintain). - if you are designing kind of generic build file, you may want to have part of this generic stuff extensible but maybe you want to restrict extension on some of your targets/datatypes that are deeply used internally. Part of the generic script can be kind of blackbox. About implementation details, i would be in favor of adding a new attribute to datatypes (like final=true), cause it make it easy to understand / read. Considering that current code base allow to modify any references and to avoid any side effect, i suggest to make the make this restriction optional . I guess if you want to make a reference unmuttable you should set it explicitly (with a final=true). !-- Example of an unmuttable reference -- myDataType id=my.reference final=true/ In any case i really hope to use the augment feature soon in easyant :). My 2 cents -- Jean Louis Boudart Independent consultant Project Lead http://www.easyant.org
Re: Augment feature
Maybe you could spread the discussion in two different parts : - adding an augment task - adding a new attribute final to datatypes +1 With AspectJ it would be possible to add an attribute final and make it be really enforced by all tasks. I am reluctant for complex features also because I am afraid we could start something that we will not have the time to finish 100% and will deliver with bugs. Make sense. As the two things (augment task / final attributes on datatypes) can be separated, maybe we could status first on the augment feature which is really simple. Introducing kind of final attribute on datatypes requires some larger discutions (due to the complexity behind). Maybe this means that there should be private references which are only accessible within a certain scope. If I understand well, in easyant you develop standard build files, which contain datatype instances with id(s) and you do not want your users to fiddle with these datatype instances. Even if there is an attribute final, users who want to change the datatype instances will find a way around it. Unless the enforcement of final=true is at the java runtime level (for instance with AspectJ). Most of the time i would like to keep it flexible, easy to use and easily extendable. Being able to augment the fileset, etc... make sense. The augment task is really appropriate here because it can strongly simplify the user experience to adapt things to their needs. On the other hand, in a few cases we need to provide structuring stuff, and changing this structure requires some reflections. So here limiting this facility by introducing kind of final=true make sense. The idea is not to lock the user and to fully restrict the access. If he want to to change structuring things he will still be able to do it but it will not be as simple as just as augmenting a datatype. Even if we provide some stucturing stuff we should not lock the user in. IMHO, this make particular sense in easyant but could also be applied in the Ant context. Regards, -- Jean Louis Boudart Independent consultant Project Lead http://www.easyant.org
Re: Augment feature
My opinion is that what we really need is a VOTE thread: 1. Are you in favor of adding the augment feature to Ant? Definitively +1 2. Are you in favor of an attribute that allows references to be marked as final, to avoid augmentation? If both things (augment task and making final references) are separated i'm +1 3. If a final attribute is decided upon, do you think it should default to false? +1 As with current code base ant datatypes are currently de-facto mutable we should keep the default value of final attribute to false. -- Jean Louis Boudart Independent consultant Project Lead http://www.easyant.org
Re: Augment feature
Of course, if people think that this hasn't been debated enough then we can continue the conversation and have the vote later. Let's please consider the fact, as pointed out by Antoine, that there is more or less no way to prevent manipulation of references by Java or scripted tasks. That being the case it doesn't seem like a good investment of cycles to prevent this task from functioning. With my just-committed bugfix to RuntimeConfigurable, my current cut of AugmentReference code is completely self-contained which means that any third party could write the task and our proposed 'final' attribute would be meaningless. What might be doable is creating another task that would make read-only a reference by dynamically generating proxies that would hide setter-type (any parameterized?) methods, or something along those lines. _That_ could stop augment and other avenues from modifying a reference if that's really what we wanted. So I'd say these are separate concerns. Sounds good to me -- Jean Louis Boudart Independent consultant Project Lead http://www.easyant.org
Re: [VOTE] release of ant 1.8.1
+1 no issue here with easyant Regards, 2010/5/1 Antoine Levy-Lambert anto...@gmx.de Hi, I have uploaded a candidate for ant 1.8.1 under http://people.apache.org/~antoine/dist/http://people.apache.org/%7Eantoine/dist/ Also a label ANT_181 has been created in the repository. Vote to release this build as ant 1.8.1 [ ] Yes [ ] No Regards, Antoine - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org -- Jean Louis Boudart Independent consultant Project Lead http://www.easyant.org
Re: [VOTE] Ant source tree reorganization
Hi, I was just wondering that if you're going to reorganize the whole source tree and have distinct structure for each produced jar, maybe we could use easyant :). Note that the next release of easyant will provide a maven-publisher plugin. Ping me if you want to POC this or have more informations In any case here is my vote : 2010/5/18 Jesse Glick jesse.gl...@oracle.com Should the Ant source tree (src/main/ and perhaps also src/tests/) be split into subtrees? [ ] No, leave it the way it is - one big tree, using selector to conditionally compile pieces and route classes to various JARs. [X] Yes, split it into subtrees, where each tree maps to an output JAR, may have its own classpath, and is compiled completely or not at all. And while we're at it: Should ant.jar and ant-nodeps.jar be consolidated? [ ] No, leave these as two JAR outputs (and two subtrees if the first proposal is accepted). [X] Yes, merge them into one ant.jar (and one subtree ), to include all tasks and types with no linkage-level deps on 3rd-party libraries (even if there is an implicit dep on a 3rd-party tool such as Perforce), and remove the Core vs. Optional distinction in the manual. -- Jean Louis Boudart Independent consultant Project Lead http://www.easyant.org
Re: Ivy 2.2.0-RC1
Hi Maarten, Any chance to get a release date for this RC ? Thanks in advance, -- Jean Louis Boudart Independent consultant Project Lead http://www.easyant.org
Re: Ivy 2.2.0-RC1
Is there anything i can do to help you on this ? I'm planning to release next easyant distribution soon and i would like it to be based on Ivy 2.2.0-RC1. We've made a few tests on our side with a trunk build and we didn't notice any problems or regressions so far. 2010/6/24 Maarten Coene maarten_co...@yahoo.com I wanted to create this RC last week, but I had some other (non-Ivy-related) issues I had to look at so I didn't had time left to create the RC. But I hope I'll be able to do it somewhere this week or next week... There are still 2 (minor) things on my todo-list for this RC: - automatically regenerate the tutorial outputs when creating a new release (almost finished on this one) - automatically run RAT against Ivy codebase and fail the build if it contains errors like missing licenses... Maarten - Original Message From: Jean-Louis Boudart jeanlouis.boud...@gmail.com To: Ant Developers List dev@ant.apache.org Sent: Thu, June 24, 2010 10:24:37 AM Subject: Re: Ivy 2.2.0-RC1 Hi Maarten, Any chance to get a release date for this RC ? Thanks in advance, -- Jean Louis Boudart Independent consultant Project Lead http://www.easyant.org - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org -- Jean Louis Boudart Independent consultant Project Lead http://www.easyant.org
Re: [VOTE] Ivy 2.2.0-rc1 release (2nd attempt)
[X] Yes 2010/6/30 Maarten Coene maarten_co...@yahoo.com Hi all, I have rebuilt Ivy 2.2.0-rc1. You can download it from this URL: http://people.apache.org/~maartenc/ivy/staging/2.2.0-rc1/http://people.apache.org/%7Emaartenc/ivy/staging/2.2.0-rc1/ A maven 2 staging repo with this release is available here: http://people.apache.org/~maartenc/m2-staging-repo/http://people.apache.org/%7Emaartenc/m2-staging-repo/ I have also created a staging Eclipse update-site here: http://people.apache.org/~maartenc/updatesite-staging/http://people.apache.org/%7Emaartenc/updatesite-staging/ Do you vote for the release of these binaries? [ ] Yes [ ] No Regards, Maarten Coene - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org -- Jean Louis Boudart Independent consultant Project Lead http://www.easyant.org
Easyant 0.8 released !
The EasyAnt project is pleased to announce its 0.8 version. Easyant is a build system, that is based on Apache Ant and Apache Ivy. Our goals are : - to leverage popularity and flexibility of Ant. - to integrate Apache Ivy, such that the build system combines a ready-to-use dependency manager. - to simplify standard build types, such as building web applications, JARs etc, by providing ready to use builds. - to provide conventions and guidelines. - to make plugging-in of fresh functionalities easy as writing simple Ant scripts as Easyant plugins. To still remain adaptable, - Though Easyant comes with a lot of conventions, we never lock you in. - Easyant allows you to easily extend existing modules or create and use your own modules. - Easyant makes migration from Ant very simple. Your legacy Ant scripts could still be leveraged with Easyant. Changelog 0.8 : Core: - Feature #132 http://easyant.org/issues/132: Switch to Ivy 2.2.0-rc1 - Feature #117 http://easyant.org/issues/117: Switch to ant 1.8.1 - Feature #136 http://easyant.org/issues/136: Introduce bindtarget task This tasks allow to change the mapping between target and phases. - Feature #137 http://easyant.org/issues/137: Introduce findclasspath task This task is designed to locate the right version of a SDK (for groovy / scala, but maybe for others SDK like android etc...). - Feature #138 http://easyant.org/issues/138: Introduce registerartifact task This task is in charge to register a given artifact to ivy context. In other words, this task is responsible of generating the right elements in the publicated module.ivy file. - Feature #70 http://easyant.org/issues/70: Introduce a menu generator task This task is used by documentation plugins (like xooki) to generate menu entries - Feature #116 http://easyant.org/issues/116: Introduce CheckResolver task to enforce plugin stability - Feature #124 http://easyant.org/issues/124: Introduce a ant task to run an easyant build process - Feature #100 http://easyant.org/issues/100: support for extends=info in ivy module parser - Feature #101 http://easyant.org/issues/101: publish merged version of Ivy descriptor when using module inheritence (extend tag in a module.ivy file) - Feature #119 http://easyant.org/issues/119: EasyAnt's launch scripts now support alternative ant distribution - Feature #122 http://easyant.org/issues/122: Simplify usage of project ivy settings (if exists use ivysettings.xml at the root level of the project) - Many bug fixes on core and documentation (plugin documentation now contains examples) - Simplify the build process of easyant core itself Plugins : - Feature #94 http://easyant.org/issues/94: Introduce package-test-jar plugin - Feature #113 http://easyant.org/issues/113: Introduce maven-publication plugin - Feature #127 http://easyant.org/issues/127: Introduce distribution plugin - Feature #115 http://easyant.org/issues/115: Add support for integration tests - Feature #123 http://easyant.org/issues/123: Support filterset in resources-std plugin - Feature #98 http://easyant.org/issues/98: Support for pre-module-phases in multi module - Feature #128 http://easyant.org/issues/128: Add a new target on skeleton plugin to choose a skeleton from a list - Feature #111 http://easyant.org/issues/111: implement xooki menugenerator - Feature #92 http://easyant.org/issues/92: eadoc plugin should use ant uptodate check to improve performance - Feature #93 http://easyant.org/issues/93: add resource collection support to junit plugin - Feature #109 http://easyant.org/issues/109: Homogenize properties referencing the main class - Several bugfixes on - skeleton - mannifest - antunit - ivy-provisionning You can have further details on EasyAnt 0.8 in the release noteshttp://easyant.org/versions/show/6 . Issues should be reported to: http://easyant.org/projects/easyant Retrieve sources from the 0.8 release files at: http://svn.easyant.org/tags/0.8/ Or download the 0.8 release files at: http://www.easyant.org/projects/easyant/files Online documentation is accessible at : http://www.easyant.org/doc/ More information can be found on the Easyant website: http://www.easyant.org/ Regards, -- Jean Louis Boudart Independent consultant Project Lead http://www.easyant.org
Re: Review Needed for Publishing Maven Artifacts with Ivy Doc
Hi there, ivy:deliver is used to generate the ivy.xml before publication based on the last resolved informations. Why are we generating an ivy.xml here ? Because when publishing, ivy adds some attributes in the generated ivy.xml file (like publication date, publication revision, publication branch). One other goal of the ivy:deliver is to replace dynamic revisions in project dependencies (if you use latest.revision, or [2.2.+[ or stuff like that in your dependencies). To sum up ivy:deliver fixes every dynamic value in the ivy.xml file to make it reproducible. ivy:publish can make the deliver process if you haven't do it explictly before. So you can consider ivy:deliver as optionnal. In some cases, invoking explicitly ivy:deliver is required : - If you want to do some post processing on ivy.xml file before publishing - If you're using recursive delivery HTH 2010/10/8 Stefan Bodewig bode...@apache.org Hi, I have one issue that is slowly bubbling up on my TODO list: I promised to provide Ant+Ivy content for http://www.apache.org/dev/publishing-maven-artifacts.html Rather than starting a lengthy thread on this list, I've created a Wiki page http://wiki.apache.org/ant/PublishingMavenArtifactsWithAntAndIvy Please review what I've written, in particular the Ivy specific parts since I'm really a newbie when it comes to Ivy. If anybody could explain to me why we use the deliver task at all, I'd be grateful. Thanks Stefan - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org -- Jean Louis Boudart Independent consultant Project Lead http://www.easyant.org
Re: Review Needed for Publishing Maven Artifacts with Ivy Doc
At the beggining of the documentation you say In addition you will need a minimal POM for your jar. Are you planning to maintain dependencies in both ivy.xml / pom.xml manually? Ivy offers a task that can generate a pom.xml from a given ivy.xml ( http://ant.apache.org/ivy/history/trunk/use/makepom.html). However the support is quite limited and provided many limations. I'll get back later with some additional informations on the limitations and already possible alternatives. Stay tuned :p 2010/10/8 Jean-Louis Boudart jeanlouis.boud...@gmail.com Hi there, ivy:deliver is used to generate the ivy.xml before publication based on the last resolved informations. Why are we generating an ivy.xml here ? Because when publishing, ivy adds some attributes in the generated ivy.xml file (like publication date, publication revision, publication branch). One other goal of the ivy:deliver is to replace dynamic revisions in project dependencies (if you use latest.revision, or [2.2.+[ or stuff like that in your dependencies). To sum up ivy:deliver fixes every dynamic value in the ivy.xml file to make it reproducible. ivy:publish can make the deliver process if you haven't do it explictly before. So you can consider ivy:deliver as optionnal. In some cases, invoking explicitly ivy:deliver is required : - If you want to do some post processing on ivy.xml file before publishing - If you're using recursive delivery HTH 2010/10/8 Stefan Bodewig bode...@apache.org Hi, I have one issue that is slowly bubbling up on my TODO list: I promised to provide Ant+Ivy content for http://www.apache.org/dev/publishing-maven-artifacts.html Rather than starting a lengthy thread on this list, I've created a Wiki page http://wiki.apache.org/ant/PublishingMavenArtifactsWithAntAndIvy Please review what I've written, in particular the Ivy specific parts since I'm really a newbie when it comes to Ivy. If anybody could explain to me why we use the deliver task at all, I'd be grateful. Thanks Stefan - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org -- Jean Louis Boudart Independent consultant Project Lead http://www.easyant.org -- Jean Louis Boudart Independent consultant Project Lead http://www.easyant.org
Re: Submitting EasyAnt project to Apache Software Foundation
being to deliver a build system using ant and ivy with a set of conventions allowing most likely to setup builds very fast if one is happy with the default conventions. I have never used easyant nor gradle but from what I can read on both web sites I would prefer a priori gradle. The fact that gradle scripts are written in groovy and so have a natural support for all usual language constructs such as if statements and loops is useful, especially when one uses ant to do deployments or other automation tasks. That being said I am not going to veto easyant joining the ASF and becoming part of the ant family of projects. I see that we will get that way more committers for ant and the ant family of projects will probably benefit from becoming bigger. Regards, Antoine On 11/12/2010 5:45 AM, Nicolas Lalevée wrote: Needless to say that I am highly supportive of this proposal, and I am willing to help in the process. Following the incubator's doc [1], I would say that a good fit for a Sponsor would be Apache Ant. We shall vote if there is no prior objection. Then about Mentors and a Champion, I am not myself qualified, even if I am motivated. So we are seeking here for a Champion and some Mentors :) Nicolas [1] http://incubator.apache.org/incubation/Roles_and_Responsibilities.html Le 11 nov. 2010 à 19:19, Jean-Louis Boudart a écrit : Hi, EasyAnt team would like to get more visibility and build a bigger community based on real open source spirit. As we're already based on many Apache project (Ant + Ivy), it seems natural for us that Apache Software Foundation could be a good host for this. Before starting the proposal process ( http://incubator.apache.org/guides/proposal.html) i would like to know if there is anybody here that can help us in this process. Project Context : - Easyant is a build system based on Apache Ant and Apache Ivy. Our goals are : * to leverage popularity and flexibility of Ant. * to integrate Apache Ivy, such that the build system combines a ready-to-use dependency manager. * to simplify standard build types, such as building web applications, JARs etc, by providing ready to use builds. * to provide conventions and guidelines. * to make plugging-in of fresh functionalities easy as writing simple Ant scripts as Easyant plugins. To still remain adaptable, * Though Easyant comes with a lot of conventions, we never lock you in. * Easyant allows you to easily extend existing modules or create and use your own modules. * Easyant makes migration from Ant very simple. Your legacy Ant scripts could still be leveraged with Easyant. Legal part : The code has been developed under the ASL2 license and by six developpers: Xavier Hanin, Jérôme Benois, Jason Trump, Siddhartha Purkayastha, Nicolas Lalevée and me. I've already discussed about this with our team, they are joining me in this request and are willing to sign any software grant paper necessary. -- Jean Louis Boudart Independent consultant Project Lead http://www.easyant.org - 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 -- Jean Louis Boudart Independent consultant Project Lead http://www.easyant.org
Re: Submitting EasyAnt project to Apache Software Foundation
2010/11/16 Antoine Levy-Lambert anto...@gmx.de On 11/12/2010 5:45 AM, Nicolas Lalevée wrote: Needless to say that I am highly supportive of this proposal, and I am willing to help in the process. Following the incubator's doc [1], I would say that a good fit for a Sponsor would be Apache Ant. We shall vote if there is no prior objection. Then about Mentors and a Champion, I am not myself qualified, even if I am motivated. So we are seeking here for a Champion and some Mentors :) The incubator doc says that someone who is a member of the PMC of the sponsoring project can also be a champion. Nicolas, I think you should be the champion, and then I could be a mentor, and probably one or two other Ant PMC members could also be mentors ? thank you for joining us in this process -- Jean Louis Boudart Independent consultant Project Lead http://www.easyant.org
Re: Command Line Debugging
The idea really looks like promising. I think this feature could have a better place in ant itself (i'm adding them in copy of this email). Could you share the code of your POC somewhere with some guide line to test it? I'm pretty sure people will have ideas when they will try it. If you need a place to publish it you can use this : https://svn.apache.org/repos/asf/incubator/easyant/tasks/trunk/. 2011/5/29 Purkayastha, Siddhartha siddhartha.purkayas...@ca.com Hello All - I wanted to discuss an idea with you about diagnostics. When considering about diagnostics, it should comprise of a set of tools that can help me diagnose issues I am facing with my build. Ant -diagnostics returns lots of variables that can be valuable to resolving environment / setup issues. I am thinking of the possibility of a Command Line Debugger / Inspector included within EasyAnt (or may be even Ant itself). I am not aware if such a tool already exists. It could behave something like this: I can run: ant -breakAt=someTarget The breakAt parameter could indicate a breakpoint at target 'someTarget'. The user could be interactively displayed a prompt here: breakpoint: [Debugger] DEBUGGER Where the user could issue a set of commands to inspect the state of the build so far. For example: breakpoint: [Debugger] DEBUGGER inspect some.property Property Value: HelloWorld The same idea could be extended to include other build factors, like paths, imported plugins etc. It may actually be extended to become a fully featured command line debugger, from where one can also set new property values or override existing values (probably a relaxation of immutability for the support of this tool) etc, do step over, step into etc. I did some experiments with this concept, I was able to break at a certain target and inspect values of properties that user wants to see, using a new target created at Runtime, with a single task that accepted user inputs from command line, interpreted it and displayed an output - And kept on doing so till the user typed 'return' on the prompt. I also think, as an extension - if we can also track audit history of different properties, paths, references etc, then this could be an effective tool. However, I do not think it is easily achievable today. I am wondering about the technical feasibility and utility of such an inbuilt tool. Can you share your thoughts on this? Thanks, Siddhartha -- Jean Louis Boudart Independent consultant Project Lead http://www.easyant.org
Re: [VOTE] Drop JDK 1.4 after 1.8.3
+1 2012/1/30 Martijn Kruithof j...@apache.org +1 (w move to 1.9) Martijn Op 30-1-2012 11:22, Peter Reilly schreef: + 1 and move to 1.9 Yey, we may even dabble in these new fangled generics Peter On Mon, Jan 30, 2012 at 8:40 AM, Dominique Devienneddevie...@gmail.com wrote: On Sat, Jan 28, 2012 at 6:54 AM, Stefan Bodewigbode...@apache.org wrote: On 2012-01-27, Jesse Glick wrote: As suggested in 1.8.3 thread, I propose we drop JDK 1.4 support in trunk after Ant 1.8.3 is released. It is long past EOL http://www.oracle.com/**technetwork/java/eol-135779.**htmlhttp://www.oracle.com/technetwork/java/eol-135779.html and cumbersome to even get installed for testing. (Note that JDK 5 is also past EOL, but I am not proposing dropping JDK 5 support in this vote.) +1 for dropping Java 1.4 support in trunk after 1.8.3. I'm with Maarten that we should switch to 1.9.0 in trunk then. +1. --DD --**--** - 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 --**--**- To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org -- Jean Louis Boudart Independent consultant Apache EasyAnt commiter http://incubator.apache.org/easyant/
Re: Fwd: extends buildlist on 2.3.0-rc1 ... it gets worse
I can try to spend some time on it but i need a reproducable use case.
Opening a JIRA and attaching a test case could save hours.
Le 22 juin 2012 23:24, Maarten Coene maarten_co...@yahoo.com a écrit :
Hi Mitch,
I've just replied on the ivy-user mailing list.
I think this issue should get fixed before the 2.3.0 final release.
Could you at least create a JIRA issue for this bug. Attaching a test case
would be really helpfull.
(attaching a patch that fixes the problem would be even more helpfull :-) )
I don't have time right now to look at it though.
I hope to have a bit more time in july/august...
Maarten
From: Mitch Gitman mgit...@gmail.com
To: Ant Developers List dev@ant.apache.org
Sent: Friday, June 22, 2012 7:53 PM
Subject: Fwd: extends buildlist on 2.3.0-rc1 ... it gets worse
I'm forwarding this thread I started on the ivy-user list.
Can someone advise me how to handle this? Should I file a JIRA issue? Is
someone aware if there's a JIRA issue already for this problem? For that
matter, has anyone else noticed Ivy buildlist and extends not being able to
coexist?
Once we've established that there's a JIRA issue with a reproducible use
case, what's the best way to ensure it gets addressed? Would someone like
Maarten want to tackle this, or should I? My fear is that, if I tackle it,
the fix is not going to find its way into the code base.
Well, my bigger fear is that Ivy 2.3.0 is going to be released without this
problem being addressed.
-- Forwarded message --
From: Mitch Gitman mgit...@gmail.com
Date: Fri, Jun 22, 2012 at 10:21 AM
Subject: Re: extends buildlist on 2.3.0-rc1 ... it gets worse
To: ivy-u...@ant.apache.org
OK, I stripped away all use of the extends feature, and sure enough,
buildlist produced a normal, expected, non-randomized project build order.
This indicates that something that had been working in Ivy 2.2.0 is no
longer working in Ivy 2.3.0-rc1.
Considering that:
A. The buildlist task is a prerequisite for being productive with Ivy.*
B. The extends feature is a prerequisite for being productive with Ivy.*
The apparent fact that these two features are now mutually exclusive with
Ivy 2.3.0-rc1 (where they weren't with Ivy 2.2.0) represents a serious bug.
I think my next step is to forward this thread to the ant-dev list and ask
how to proceed.
* For those who wish to say, Mitch, we've been able to get by just fine
without (buildlist|extends), I'm perfectly happy to have that discussion,
but my primary concern now is facilitating a fix.
On Thu, Jun 21, 2012 at 10:12 PM, Mitch Gitman mgit...@gmail.com wrote:
One other data point. As long as my undesired simplification wasn't
helping things, I went back to both a bootstrap-parent and a
master-parent.
I also tried setting haltOnError=false on ivy:buildlist. With that, the
task successfully got through everything. However, it continued to
create a
seriously trashed build order.
Just as an experiment, I might try converting all the ivy.xml files to
not
use the extends feature and then see what happens when running buildlist.
My hypothesis is, this will work. Not that this is a desired state of
affairs, but at least it isolates the problem to the interaction between
buildlist and extends.
On Thu, Jun 21, 2012 at 9:23 PM, Mitch Gitman mgit...@gmail.com wrote:
Over a week ago, I'd sent out a message to this list, buildlist task
chokes on absolute path to parent Ivy module. I'd found that the
extends
feature worked fine with an absolute path to the parent ivy.xml if I was
building any single Ivy module, but the buildlist task would fail to
find
the absolute path.
I'd noted that I'd been using Ivy 2.2.0. Now that I've upgraded to Ivy
2.3.0-rc1, my problems have only gotten worse. The first problem I
encountered had nothing to do with absolute paths to parents. I'm still
using relative paths to parents. Instead, it arose from my using two
different parent Ivy modules: bootstrap-parent and master-parent. Some
projects extended the former; others the latter. For example:
info organisation=foo module=homeowner revision=${version}
extends organisation=foo module=bootstrap-parent
revision=${version}
location=../bootstrap-parent/ivy.xml /
/info
But then when I pointed the ivy:buildlist Ant task at a project stack
that included a mix of both parents and their children, I saw this
error:
impossible to parse ivy file for …/foo-client/homeowner/build.xml:
ivyfile=.../foo-client/homeowner/ivy.xml
exception=java.text.ParseException: Problem occurred while parsing ivy
file: inconsistent module descriptor file found in
'file:/.../master-parent/ivy.xml': bad module name:
expected='bootstrap-parent' found='master-parent'; in
file:/.../foo-client/homeowner/ivy.xml
What's happening is, the homeowner module extends
Re: [VOTE] Accept EasyAnt as a subproject
I was watching the original discussion on incubator mailing list few days ago, and like Nicolas i misunderstood the sponsoring of Ant project to EasyAnt. I don't see any advantage to build an independent PMC. EasyAnt is build on top of ant and ivy, and it doesn't mean we just want to use the library under the hood. EasyAnt is here also to promote those powerful tools and bring fresh ideas, we already contributed features to both project, and i'm pretty sure we will continue in this way. As we depend on those project and really plan to contribute to them i would feel more confortable if Ant PMC is aware about easyant release and vice et versa. EasyAnt will try to be always using upstream version of both project, and particular needs for us could probably stimulate ant or ivy release frequency. If one day, some of us becomes part of Ant PMC, we could also help on releasing Ant + Ivy. Cheers, 2012/7/11 Nicolas Lalevée nicolas.lale...@hibnet.org EasyAnt is a project based on Ant and Ivy which is in incubation under our sponsoring. I kind of misunderstood the sponsoring. I was thinking that it was implying that EasyAnt will become part of the Ant project. It doesn't bylaw. We just cleared it out with the EasyAnt community. So let's clear it out with this vote for the Ant PMC. I also thought that EasyAnt should have a classical incubation period, doing release and growing a community. But it has no sense since if EasyAnt is accepted as a subproject of Ant, the Ant PMC will be responsible for EasyAnt code and releases. So if we accept EasyAnt, the code will be imported, committers added. But releases should be voted by us. I'm the only active EasyAnt committer which is also an Ant PMC member. This means that other Ant PMC member should be involved so that things can roll. We have been managing that with Ivy and IvyDE, but this is something that should have in mind while voting. Also note that it would somehow resolve itself it some EasyAnt developer become part of the Ant PMC, some of them have already wrote some nice patches on Ant and Ivy :) So, should we accept EasyAnt as a subproject ? Nicolas - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org -- Jean Louis Boudart Independent consultant Apache EasyAnt commiter http://incubator.apache.org/easyant/
Re: [VOTE] Accept EasyAnt as a subproject
This topic doesn't look like popular :) Should we consider this silence as a no go? 2012/7/16 Nicolas Lalevée nicolas.lale...@hibnet.org explicitly binding my vote: +1 Nicolas Le 11 juil. 2012 à 10:48, Nicolas Lalevée a écrit : EasyAnt is a project based on Ant and Ivy which is in incubation under our sponsoring. I kind of misunderstood the sponsoring. I was thinking that it was implying that EasyAnt will become part of the Ant project. It doesn't bylaw. We just cleared it out with the EasyAnt community. So let's clear it out with this vote for the Ant PMC. I also thought that EasyAnt should have a classical incubation period, doing release and growing a community. But it has no sense since if EasyAnt is accepted as a subproject of Ant, the Ant PMC will be responsible for EasyAnt code and releases. So if we accept EasyAnt, the code will be imported, committers added. But releases should be voted by us. I'm the only active EasyAnt committer which is also an Ant PMC member. This means that other Ant PMC member should be involved so that things can roll. We have been managing that with Ivy and IvyDE, but this is something that should have in mind while voting. Also note that it would somehow resolve itself it some EasyAnt developer become part of the Ant PMC, some of them have already wrote some nice patches on Ant and Ivy :) So, should we accept EasyAnt as a subproject ? Nicolas - 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 -- Jean Louis Boudart Independent consultant Apache EasyAnt commiter http://incubator.apache.org/easyant/
Re: Ivy 2.3.0-RC2 ?
i'm ready to beta test it within easyant :) Le 23 oct. 2012 11:02, Nicolas Lalevée nicolas.lale...@hibnet.org a écrit : Le 22 oct. 2012 à 23:27, Maarten Coene maarten_co...@yahoo.com a écrit : Hi, I would like to try to create a new Ivy release candidate next weekend (27/28 October) I'm not sure yet if I will have the time, but if no-one objects I'll give it a try. ok for me Nicolas - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
RE: [RESULT][VOTE] Jean-Louis Boudart as committer
Thanks for your votes guys ! Le 30 oct. 2012 20:24, Martin Gainty mgai...@hotmail.com a écrit : Félicitations Jen-Louis Bienvenue sur Ant Martin __ Note de déni et de confidentialité Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni. Subject: [RESULT][VOTE] Jean-Louis Boudart as committer From: nicolas.lale...@hibnet.org Date: Tue, 30 Oct 2012 20:18:14 +0100 To: dev@ant.apache.org I count 5 binding +1. No -1 nor 0. The vote pass. Congratulation Jean-Louis ! Nicolas Le 23 oct. 2012 à 10:58, Nicolas Lalevée nicolas.lale...@hibnet.org a écrit : Jean-Louis has been nicely involved with both Ant and Ivy for some time. Let's vote to invite him to be an Ant committer. [ ] +1 to add Jean-Louis as a committer [ ] -1 to disagree (because…) [ ] +/-0 I don't care Nicolas - 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
RE: [RESULT][VOTE] Jean-Louis Boudart as committer
I have a present for Ivy project to celebrate this news (a new feature ? maybe). Stay tuned :) *teasing* Le 30 oct. 2012 20:28, Jean-Louis Boudart jeanlouis.boud...@gmail.com a écrit : Thanks for your votes guys ! Le 30 oct. 2012 20:24, Martin Gainty mgai...@hotmail.com a écrit : Félicitations Jen-Louis Bienvenue sur Ant Martin __ Note de déni et de confidentialité Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni. Subject: [RESULT][VOTE] Jean-Louis Boudart as committer From: nicolas.lale...@hibnet.org Date: Tue, 30 Oct 2012 20:18:14 +0100 To: dev@ant.apache.org I count 5 binding +1. No -1 nor 0. The vote pass. Congratulation Jean-Louis ! Nicolas Le 23 oct. 2012 à 10:58, Nicolas Lalevée nicolas.lale...@hibnet.org a écrit : Jean-Louis has been nicely involved with both Ant and Ivy for some time. Let's vote to invite him to be an Ant committer. [ ] +1 to add Jean-Louis as a committer [ ] -1 to disagree (because…) [ ] +/-0 I don't care Nicolas - 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
Re: [VOTE] Apache Ivy 2.3.0-RC2 release (2nd attempt)
+1 Le 6 nov. 2012 14:07, Nicolas Lalevée nicolas.lale...@hibnet.org a écrit : +1 Nicolas Le 5 nov. 2012 à 23:37, Maarten Coene maarten_co...@yahoo.com a écrit : Hi all, Here is a new attempt to create the Apache Ivy 2.3.0-RC2 release. The only change compared to the first attempt is the version fix for the OSGI bundle. You can find the binaries here: https://dist.apache.org/repos/dist/dev/ant/ivy/2.3.0-rc2/ A staging maven repository can be found here: https://repository.apache.org/content/repositories/orgapacheant-017/ The SVN tag: https://svn.apache.org/repos/asf/ant/ivy/core/tags/2.3.0-rc2/ Do you vote for the release of these binaries? [ ] Yes [ ] No regards, Maarten Coene - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: [RESULT][VOTE] Apache Ivy 2.3.0-RC2 release (2nd attempt)
I could also give some help but i dont know where to start. Is the whole release process documented ? If yes could give me some pointers? Le 12 nov. 2012 23:09, Maarten Coene maarten_co...@yahoo.com a écrit : Thanks Nicolas, that would be really helpful! :-) Maarten From: Nicolas Lalevée nicolas.lale...@hibnet.org To: Ant Developers List dev@ant.apache.org Sent: Monday, November 12, 2012 11:02 PM Subject: Re: [RESULT][VOTE] Apache Ivy 2.3.0-RC2 release (2nd attempt) Le 12 nov. 2012 à 22:49, Maarten Coene maarten_co...@yahoo.com a écrit : Hi all, I'm pleased to announce that the vote for the Apache Ivy 2.3.0-RC2 release has passed. There were +1 votes from Nicolas, Jean-Louis, Antoine and myself. I'll continue the release process the next couple of days. I can help with the Eclipse update site if you want. Nicolas - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: [VOTE] Apache Ivy 2.3.0 release
+1 Tested within easyant and everything is fine :) 2013/1/13 Maarten Coene maarten_co...@yahoo.com Hi all, I've created the binaries containing the Apache Ivy 2.3.0 release. These binaries can be found here: https://dist.apache.org/repos/dist/dev/ant/ivy/2.3.0/ Maven artifacts are here: https://repository.apache.org/content/repositories/orgapacheant-125/ Eclipse Update site is located here: https://dist.apache.org/repos/dist/dev/ant/ivyde/updatesite/ivy-2.3.0.final_20130110142753/ They are based on the following tag: https://svn.apache.org/repos/asf/ant/ivy/core/tags/2.3.0/ Do you vote for the release of these binaries? [ ] +1 Release these artifacts [ ] +0 OK, but... [ ] -0 OK, but really should fix... [ ] -1 I oppose this release because... kind regards, Maarten Coene -- Jean Louis Boudart
Re: [VOTE] Accept EasyAnt as a subproject - take 2
[x] +1, I accept 2013/2/27 Nicolas Lalevée nicolas.lale...@hibnet.org Hi, This is the come back of the proposal of bringing EasyAnt under the umbrella of the Ant PMC. There were some discussion on incubator-general about the incubating hcatalog project being graduated under the umbrella of the Hive PMC. I think that our case is more clear and more standard regarding the ASF rules, but I'll remind here what is at stake, so there is no misunderstanding (I include myself on the potentially misunderstanding people). EasyAnt code will be brought into Ant's svn tree. EasyAnt committers will become Ant committers but not part of the PMC (on 5 committers, 3 are already Ant ones, and 2 are part of Ant's PMC) The Ant PMC will be responsible for the code, the community, the next releases of EasyAnt. Just like for Ivy. And I like the way it worked. Further more considering my path, I think it is good that there is no special right management in svn. I started as an IvyDE committer, I ended improving myself Ivy and Ant. Since the last vote tentative, the activity on EasyAnt remained the same, somehow low but continuous, not much less than Ant developers activity. And lately we succeeded to get a release out. To get yourself an opinion, here are some links: - the EasyAnt project incubator page: http://incubator.apache.org/projects/easyant.html - the archive of the mailing lists http://mail-archives.apache.org/mod_mbox/incubator-easyant-commits/ http://mail-archives.apache.org/mod_mbox/incubator-easyant-dev/ - the release http://www.apache.org/dist/incubator/easyant So, should we accept EasyAnt as a subproject ? Please, cast your votes: [ ] +1, I accept [ ] +0, OK, but…. [ ] -1, I disapprove, because…. Nicolas - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org -- Jean Louis Boudart Independent consultant Apache EasyAnt commiter http://incubator.apache.org/easyant/
Re: [VOTE] Accept EasyAnt as a subproject - take 2
We will publish a updated documentation soon (probably tonight). Currently, the community is really small as prior releases was using patched version of Ant and Ivy (mainly to introduce missing features sur as extensionPoints in Ant, or module inheritence in Ivy). This was probably a major issue, and explain why we didn't communicate too much outside of ant-dev mailing list about it. We've made lot of work to contribute back our modifications to both tools and we now use official releases. In future we plan to bring more valuable features to both Ant and Ivy. This is one of the main reason motivating us to enter in ASF. In the meantime we changed a lot of structuring stuff in easyant itself to remain flexible and easier to use. This release is a huge step for the project. And it's now time to promote EasyAnt as a usable tool and to widen the community. Your feedback will be really appreciated. 2013/2/28 Tim Enderling t.enderl...@intershop.de Hi, I didn't know that EasyAnt is still alive. EasyAnt might be exactly what we are looking for in a solution to modularize our build system and software. Some questions: Is there a more up-to-date documentation than the one at http://incubator.apache.org/easyant/history/trunk/reference.html?Fromskimming through (and besides there a quite a few obvious mistakes in it) it seems to refer to a release prior to 0.9. Also: How large is the community of EasyAnt, are there any references for software projects using it? (I tried to get an idea for that by searching for EasyAnt on stackoverflow, but that didn't turn out well.) Thanks a lot Tim Enderling -Original Message- From: Nicolas Lalevée [mailto:nicolas.lale...@hibnet.org] Sent: Mittwoch, 27. Februar 2013 19:44 To: Ant Developers List Subject: [VOTE] Accept EasyAnt as a subproject - take 2 Hi, This is the come back of the proposal of bringing EasyAnt under the umbrella of the Ant PMC. There were some discussion on incubator-general about the incubating hcatalog project being graduated under the umbrella of the Hive PMC. I think that our case is more clear and more standard regarding the ASF rules, but I'll remind here what is at stake, so there is no misunderstanding (I include myself on the potentially misunderstanding people). EasyAnt code will be brought into Ant's svn tree. EasyAnt committers will become Ant committers but not part of the PMC (on 5 committers, 3 are already Ant ones, and 2 are part of Ant's PMC) The Ant PMC will be responsible for the code, the community, the next releases of EasyAnt. Just like for Ivy. And I like the way it worked. Further more considering my path, I think it is good that there is no special right management in svn. I started as an IvyDE committer, I ended improving myself Ivy and Ant. Since the last vote tentative, the activity on EasyAnt remained the same, somehow low but continuous, not much less than Ant developers activity. And lately we succeeded to get a release out. To get yourself an opinion, here are some links: - the EasyAnt project incubator page: http://incubator.apache.org/projects/easyant.html - the archive of the mailing lists http://mail-archives.apache.org/mod_mbox/incubator-easyant-commits/ http://mail-archives.apache.org/mod_mbox/incubator-easyant-dev/ - the release http://www.apache.org/dist/incubator/easyant So, should we accept EasyAnt as a subproject ? Please, cast your votes: [ ] +1, I accept [ ] +0, OK, but.. [ ] -1, I disapprove, because.. Nicolas - 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 -- Jean Louis Boudart Independent consultant Apache EasyAnt commiter http://incubator.apache.org/easyant/
Fwd: [ANNOUNCE] Apache EasyAnt 0.9-incubating released
The Apache EasyAnt project is pleased to announce its 0.9-incubating release. Apache Easyant is a toolbox focusing on easing project build processes. It's based on Apache Ant and Apache Ivy, and allows for maximum flexibily, improved integration in existing build systems and provides conventions and guidelines. Our goals are : - to leverage popularity and flexibility of Ant. - to integrate Apache Ivy, such that the build system combines a ready-to-use dependency manager. - to simplify standard build types, such as building web applications, JARs etc, by providing ready to use builds. - to provide conventions and guidelines. - to make plugging-in of fresh functionalities as easy as writing Ant scripts. To still remain adaptable, - Though EasyAnt comes with a lot of conventions, we never lock you in. - EasyAnt allows you to easily extend existing modules or create and use your own modules. - EasyAnt makes migration from Ant very simple. Your legacy Ant scripts could still be leveraged using EasyAnt. Key features of this 0.9-incubating release are : - dynamic project lifecycle to remain even more flexible (get rid of phases in favor of extension point) - enhanced multimodule support - enhanced exception handling - support for offline mode - new command line switches and related api to list and describe targets, properties, extensionPoints and even parameters (path, filesets) - plugin dependencies can be overridden in module descriptors - a set of new ant tasks to make plugin writer life easier - a lighter distribution with only core plugins/buildtypes - online repository for others plugins/buildtypes/skeletons - upgrade to Apache Ant 1.8.4 and Apache Ivy 2.3.0 - numerous bug fixes as documented in Jira and in the release notes This is the first EasyAnt release under Apache Software Foundation. You can download this 0.9-incubating release at: http://incubator.apache.org/easyant/download.cgi Issues should be reported to: https://issues.apache.org/jira/browse/EASYANT More information can be found on the website: http://incubator.apache.org/easyant/ Regards, -- Jean Louis Boudart
Re: [VOTE] Ant 1.9.0 release [2nd attempt]
+1 on the release as is too Works perfectly in easyant :) 2013/3/9 Stefan Bodewig bode...@apache.org +1 on the release as is. On 2013-03-08, Antoine Levy Lambert wrote: You can veto the release if it matters that much to you and I would then have to drop and recreate the 1.9.0 label and do a new build. Maybe I'm picking nits: you can't veto a release, this is a majority vote. Stefan - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org -- Jean Louis Boudart Independent consultant Apache EasyAnt commiter http://incubator.apache.org/easyant/
Re: [VOTE] Michael Clarke as a committer
+1 Le 12 mars 2013 20:39, Maarten Coene maarten_co...@yahoo.com a écrit : +1 Maarten From: Bruce Atherton br...@callenish.com To: dev@ant.apache.org Sent: Tuesday, March 12, 2013 6:03 PM Subject: [VOTE] Michael Clarke as a committer I'd like to nominate Michael Clarke as a committer. Not only has he revamped our testing infrastructure to make it compatible with JUnit4, he has also worked on resolving older bugs in our bugzilla that touched on testing. Let's vote on it. [ ] +1 to add Michael Clarke as a committer [ ] -1 to disagree [ ] ±0 means I don't care. Here is my +1. Bruce - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: EasyAnt is graduating
All infra request are now closed. Migration seems over! Long live http://ant.apache.org/easyant/ PS: i think we forgot setuping redirection from incubator.a.o/easyant to ant.a.o/easyant. I will fix this today Le 23 mars 2013 15:25, Nicolas Lalevée nicolas.lale...@hibnet.org a écrit : Le 16 mars 2013 à 01:39, Nicolas Lalevée nicolas.lale...@hibnet.org a écrit : Finally ! We're there ! Now we need to move stuff. EasyAnt is graduating like Ivy did, so about the resources, here is the following suggestions. * The svn tree We will move the svn tree of EasyAnt under Ant's one. Everything except 'KEYS' and 'site' under http://svn.apache.org/repos/asf/incubator/easyant/will move into http://svn.apache.org/repos/asf/ant/easyant. done. We'll give write rights to EasyAnt committers on the entire Ant svn tree. We need to give r/w rights to Jérôme Benois (jbenois) and Siddhartha Purkayastha (kpsiddharth). * The website EasyAnt website is using the same publication mechanism as Ant. We'll need to move the svn tree of the site from http://svn.apache.org/repos/asf/incubator/easyant/site/ to http://svn.apache.org/repos/asf/ant/site/easyant. done. The web site will be at http://ant.apache.org/easyant We'll need to create an INFRA ticket about the move: - redirect from incubator/esayant to ant.apache.org/easyant (via http://svn.apache.org/repos/asf/incubator/public/trunk/content/.htaccess) I'll do as soon as the following infra ticket is closed. - change the svnpubsub https://issues.apache.org/jira/browse/INFRA-6048 * The mailing lists: - easyant-dev@ will be closed in favor of dev@ant.apache.org - easyant-commits@ will be closed in favor of notificati...@ant.apache.org - easyant-private@ just closed. https://issues.apache.org/jira/browse/INFRA-6049 * Jira: No need to do anything I think: https://issues.apache.org/jira/browse/EASYANT Just need to notify the infra that the notification list is now notificati...@ant.apache.org https://issues.apache.org/jira/browse/INFRA-6050 Maybe some changes in the Gump metadata and Jenkins jobs? Good catch. There is nothing in Gump about EasyAnt but there is in Jenkins. I'll update it too. done. Nicolas - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: easyant4e binary
Hi, Unfortunatly, easyant4e isn't released yet ! We still have work on it to sync with recent changes of easyant. 2013/4/2 Tim Enderling t.enderl...@intershop.de Hi, is easyant4e available as a prebuilt package/is there an Eclipse update site for it? Best regards Tim Enderling - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org -- Jean Louis Boudart Independent consultant Apache EasyAnt commiter http://incubator.apache.org/easyant/
Re: Some feedback on EasyAnt
Hi Xavier, Thanks for your feedback ! 2013/4/15 Xavier Hanin xavier.ha...@gmail.com I've been playing a little bit with easyant 0.9 this wek-end, and I have some feedback: - I have some issues with the multi module example: - if I run easyant verify at the root I get an error: The classpath for junit must include junit.jar if not in Ant's own classpath - if I run easyant publish-local I get another error: bad revision found in ivy file (Revision: 0.2-local-20130415094618). Use forcedeliver or update Good catch i'll fix this now - from a documentation point of view, I have not found the documentation of plugins. Having links from the plugins and standard build types pages would be really nice. To change the compiler source and target version I had to check the source files. - the source files of plugins are pretty easy to read and understand, I think providing links to them or documentation on where to find them would be useful for people used to plain ant (maybe I just missed this part of the doc, I didn't read everything). Plugin documentation is not online yet. We didn't took time to find how to publish them as we may have differences in future plugin releases. We already have a way to generate plugin documentation. Adding links to plugin sources could be a good too. - I've written a small tool to convert basic (very basic I mean) pom files to module.ivy, and the result is interesting: on a bunch of modules, not only the build run perfectly well (it's really nice to use the same conventions), but also it's slightly faster: on a 22 multi module build, a easyant package take 19s against 23s for mvn -DskipTests=true install Nice to hear that it's easy to move from a standard maven build with multimodules to easyant. Will you share your tool to convert pom files to module.ivy ? To conclude there's room for improvement, but you've done a very good work especially on the maven compatibility side, which is great for people having a maven build. I plan to continue improving support for maven users. In early days of easyant we wrote a plugin to emulate maven publication (generating a pom and related metadatas) [1] . I saw ivy improvements on makepom task [2] and i believe we have work to do on both project to make life easier for maven users to reuse publicated artifacts by ivy/easyant. For the bugs and documentation improvements, I know I could contrbute myself, but I have to admit I don't have enough time to dedicate. No problem :) [1] https://svn.apache.org/repos/asf/ant/easyant/plugins/trunk/maven-publication/ [2] http://ant.apache.org/ivy/history/trunk/use/makepom.html -- Jean Louis Boudart Independent consultant Apache EasyAnt commiter http://incubator.apache.org/easyant/
Re: Some feedback on EasyAnt
What is the desired behavior when junit is missing in project classpath ? 1 - ignore test ? maybe with a message @info level ? 2 - configure the plugin to use junit version specified in the project. and if no one is specified use the one specified by us in the plugin itself ? 2013/4/15 Jean-Louis Boudart jeanlouis.boud...@gmail.com Hi Xavier, Thanks for your feedback ! 2013/4/15 Xavier Hanin xavier.ha...@gmail.com I've been playing a little bit with easyant 0.9 this wek-end, and I have some feedback: - I have some issues with the multi module example: - if I run easyant verify at the root I get an error: The classpath for junit must include junit.jar if not in Ant's own classpath - if I run easyant publish-local I get another error: bad revision found in ivy file (Revision: 0.2-local-20130415094618). Use forcedeliver or update Good catch i'll fix this now - from a documentation point of view, I have not found the documentation of plugins. Having links from the plugins and standard build types pages would be really nice. To change the compiler source and target version I had to check the source files. - the source files of plugins are pretty easy to read and understand, I think providing links to them or documentation on where to find them would be useful for people used to plain ant (maybe I just missed this part of the doc, I didn't read everything). Plugin documentation is not online yet. We didn't took time to find how to publish them as we may have differences in future plugin releases. We already have a way to generate plugin documentation. Adding links to plugin sources could be a good too. - I've written a small tool to convert basic (very basic I mean) pom files to module.ivy, and the result is interesting: on a bunch of modules, not only the build run perfectly well (it's really nice to use the same conventions), but also it's slightly faster: on a 22 multi module build, a easyant package take 19s against 23s for mvn -DskipTests=true install Nice to hear that it's easy to move from a standard maven build with multimodules to easyant. Will you share your tool to convert pom files to module.ivy ? To conclude there's room for improvement, but you've done a very good work especially on the maven compatibility side, which is great for people having a maven build. I plan to continue improving support for maven users. In early days of easyant we wrote a plugin to emulate maven publication (generating a pom and related metadatas) [1] . I saw ivy improvements on makepom task [2] and i believe we have work to do on both project to make life easier for maven users to reuse publicated artifacts by ivy/easyant. For the bugs and documentation improvements, I know I could contrbute myself, but I have to admit I don't have enough time to dedicate. No problem :) [1] https://svn.apache.org/repos/asf/ant/easyant/plugins/trunk/maven-publication/ [2] http://ant.apache.org/ivy/history/trunk/use/makepom.html -- Jean Louis Boudart Independent consultant Apache EasyAnt commiter http://incubator.apache.org/easyant/ -- Jean Louis Boudart Independent consultant Apache EasyAnt commiter http://incubator.apache.org/easyant/
Re: Some feedback on EasyAnt
Done on trunk Le 17 avr. 2013 18:32, Xavier Hanin xavier.ha...@gmail.com a écrit : On Tue, Apr 16, 2013 at 8:19 AM, Jean-Louis Boudart jeanlouis.boud...@gmail.com wrote: What is the desired behavior when junit is missing in project classpath ? 1 - ignore test ? maybe with a message @info level ? 2 - configure the plugin to use junit version specified in the project. and if no one is specified use the one specified by us in the plugin itself ? I think failing is ok, after all there is a dependency missing. My 2 c. Xavier -- Xavier Hanin - 4SH France - http://www.4sh.fr/ BordeauxJUG creator - http://www.bordeauxjug.org/ Apache Ivy Creator - http://ant.apache.org/ivy/
Re: Ant Homepage
2013/4/20 Jan Matèrne j...@materne.de I had a look at the homepage: * EasyAnt is not listed in the subproject section * There is a graphic for ApacheCon, which is over. I prepared a commit for that. Should I commit? Also I have seen that the EasyAnt homepage itself spells it Easyant or EasyAnt (sometimes with upper A and sometimes with lower a). I think it should be with upper A ;-) I also prefer with a upper A ! Not sure if I should work here ... Contributions are welcome :) After a long time of commits I want to be careful. What is the current process of updating the homepage? - modify the svn site module - run the build - commit - some more work here? Jan -- Jean Louis Boudart Independent consultant Apache EasyAnt commiter http://incubator.apache.org/easyant/
Re: Ant Homepage
2013/4/21 Jan Matèrne (jhm) apa...@materne.de I had a look at the homepage: * EasyAnt is not listed in the subproject section done * There is a graphic for ApacheCon, which is over. I think this is included dynamically from a site maintained by the ApacheCon committee - nothing much you'll be able to do. ok, keep unattended Also I have seen that the EasyAnt homepage itself spells it Easyant or EasyAnt (sometimes with upper A and sometimes with lower a). I think it should be with upper A ;-) I also prefer with a upper A ! done Thx :) Not sure if I should work here ... Contributions are welcome :) I could run a build using easyant publish-shared, but - I have to install a Java6 (Xooki) and Java5 (Ant regression) on my machine - I dont have an idea of how to generate the stuff in site\easyant\production Calling easyant publish-shared will generate final documentation in site\easyant\production, but as you pointed out it requires Java6. I'll process it tonight. Jean Louis Boudart Independent consultant Apache EasyAnt commiter http://incubator.apache.org/easyant/ @Jean Louis: new URL for EasyAnt ;-) Good catch ;) -- Jean Louis Boudart Independent consultant Apache EasyAnt commiter http://ant.apache.org/easyant/
Evaluating Bintray as a distribution platform for easyant plugins
Dear EasyAnters, I've been working on sonar integration as a plugin for easyant. Source are hosted on github :https://github.com/easyant/sonar-easyant-plugin . Since a few weeks, JFrog (guys behind Artifactory) opened a new online service for OpenSourcers : Bintray. Bintray is a social service for developers to publish, download, store, promote, and share open source software packages. With Bintray's full self-service platform developers have full control over their published software and how it is distributed to the world. What would be the benefits for easyant ? We currently have our own repostory (repository.easyant.org) hosted on a private server. I would prefer to switch to a more reliable repository like bintray. No need to worry about backup, disaster recovery. We could just focus on content. They also offers download statistics which could be interresting for us. I created a repository to host community plugins : https://bintray.com/repo/browse/easyant/community-plugins To use it add the following resolver in your ivysettings.xml url name=community-plugins artifact pattern= http://dl.bintray.com/content/easyant/community-plugins/[organisation]/[module]/[revision]/[type]s/[artifact].[ext]/ ivy pattern= http://dl.bintray.com/content/easyant/community-plugins/[organisation]/[module]/[revision]/[type]s/[artifact].[ext]/ /url Currently only sonar-easyant-plugin package is available. As bintray and github supports Markdown syntax, i made some experimentation on plugin documentation generation. Result on github : https://github.com/easyant/sonar-easyant-plugin Result on bintray : https://bintray.com/pkg/show/readmore/easyant/community-plugins/sonar-easyant-plugin If sources are on github, read more page from github can be synced with README.md. If not we can edit directly in bintray. You can notice that Table markdown syntax seems broken on bintray (or not supported yet). I reported it few minutes ago. I'm really satisfied by the result and wondering if we should move our plugins there. We can be backward compatible on exposed urll without effort. What do you think? -- Jean Louis Boudart Independent consultant Apache EasyAnt commiter http://ant.apache.org/easyant/
Re: AW: Evaluating Bintray as a distribution platform for easyant plugins
I would prefer having the artifacts on ASF servers. A (Nexus based) repository is at https://repository.apache.org/ Ant + Ivy are available at https://repository.apache.org/content/repositories/releases/ I would also prefer this but will ASF authorize non apache project (read plugins with incompatible licences for example) to publish there ? I don't think so. By the way you really got the idea, have one connection point to ease understanding for the community. That's why we intially setup a online repository (repo.easyant.org) with two internal repository : * one for apache plugins * one for non apache plugins (the one having potential issues with licenses like sonar or checkstyle) I was suggesting to reproduce this on bintray. If this could be done @ASF i would definitively go in that direction ! But is this really possible ? As bintray and github supports Markdown syntax, i made some experimentation on plugin documentation generation. Are you writing the markdown by hand or do you generate that from java source? Generated through easyant plugin report task ( http://svn.apache.org/repos/asf/ant/easyant/plugins/trunk/easyant-plugin-documentation/src/main/resources/easyant-report-mardown.xsl) with a custom xsl ( http://svn.apache.org/repos/asf/ant/easyant/plugins/trunk/easyant-plugin-documentation/src/main/resources/easyant-report-mardown.xsl ) Result on github : https://github.com/easyant/sonar-easyant-plugin Result on bintray : https://bintray.com/pkg/show/readmore/easyant/community-plugins/sonar- easyant-plugin On BinTray the tables are broken. No syntax highlighting on BT? I also reported this. Git support is growing at ASF, e.g. Camel is on the migration path from svn to git. A blocker to their vote is https://issues.apache.org/jira/browse/INFRA-6197 Nice to know :). I was talking here for non apache plugins/
Re: AW: Evaluating Bintray as a distribution platform for easyant plugins
Here is the original thread from easyant-dev ML during apache incubation : http://markmail.org/thread/uv2xkj63rkdh2thh Le 29 avr. 2013 20:53, Jean-Louis Boudart jeanlouis.boud...@gmail.com a écrit : I would prefer having the artifacts on ASF servers. A (Nexus based) repository is at https://repository.apache.org/ Ant + Ivy are available at https://repository.apache.org/content/repositories/releases/ I would also prefer this but will ASF authorize non apache project (read plugins with incompatible licences for example) to publish there ? I don't think so. By the way you really got the idea, have one connection point to ease understanding for the community. That's why we intially setup a online repository (repo.easyant.org) with two internal repository : * one for apache plugins * one for non apache plugins (the one having potential issues with licenses like sonar or checkstyle) I was suggesting to reproduce this on bintray. If this could be done @ASF i would definitively go in that direction ! But is this really possible ? As bintray and github supports Markdown syntax, i made some experimentation on plugin documentation generation. Are you writing the markdown by hand or do you generate that from java source? Generated through easyant plugin report task ( http://svn.apache.org/repos/asf/ant/easyant/plugins/trunk/easyant-plugin-documentation/src/main/resources/easyant-report-mardown.xsl) with a custom xsl ( http://svn.apache.org/repos/asf/ant/easyant/plugins/trunk/easyant-plugin-documentation/src/main/resources/easyant-report-mardown.xsl ) Result on github : https://github.com/easyant/sonar-easyant-plugin Result on bintray : https://bintray.com/pkg/show/readmore/easyant/community-plugins/sonar- easyant-plugin On BinTray the tables are broken. No syntax highlighting on BT? I also reported this. Git support is growing at ASF, e.g. Camel is on the migration path from svn to git. A blocker to their vote is https://issues.apache.org/jira/browse/INFRA-6197 Nice to know :). I was talking here for non apache plugins/
Re: AW: Evaluating Bintray as a distribution platform for easyant plugins
No objections? :p Le 29 avr. 2013 20:59, Jean-Louis Boudart jeanlouis.boud...@gmail.com a écrit : Here is the original thread from easyant-dev ML during apache incubation : http://markmail.org/thread/uv2xkj63rkdh2thh Le 29 avr. 2013 20:53, Jean-Louis Boudart jeanlouis.boud...@gmail.com a écrit : I would prefer having the artifacts on ASF servers. A (Nexus based) repository is at https://repository.apache.org/ Ant + Ivy are available at https://repository.apache.org/content/repositories/releases/ I would also prefer this but will ASF authorize non apache project (read plugins with incompatible licences for example) to publish there ? I don't think so. By the way you really got the idea, have one connection point to ease understanding for the community. That's why we intially setup a online repository (repo.easyant.org) with two internal repository : * one for apache plugins * one for non apache plugins (the one having potential issues with licenses like sonar or checkstyle) I was suggesting to reproduce this on bintray. If this could be done @ASF i would definitively go in that direction ! But is this really possible ? As bintray and github supports Markdown syntax, i made some experimentation on plugin documentation generation. Are you writing the markdown by hand or do you generate that from java source? Generated through easyant plugin report task ( http://svn.apache.org/repos/asf/ant/easyant/plugins/trunk/easyant-plugin-documentation/src/main/resources/easyant-report-mardown.xsl) with a custom xsl ( http://svn.apache.org/repos/asf/ant/easyant/plugins/trunk/easyant-plugin-documentation/src/main/resources/easyant-report-mardown.xsl ) Result on github : https://github.com/easyant/sonar-easyant-plugin Result on bintray : https://bintray.com/pkg/show/readmore/easyant/community-plugins/sonar- easyant-plugin On BinTray the tables are broken. No syntax highlighting on BT? I also reported this. Git support is growing at ASF, e.g. Camel is on the migration path from svn to git. A blocker to their vote is https://issues.apache.org/jira/browse/INFRA-6197 Nice to know :). I was talking here for non apache plugins/
Adding if/unless conditions on commandline args
Hi,
It's currently difficult to make reusable script when using exec task or
any other task using commandline args.
We oftenly need some dynamic arguments and this can be complicated.
Therefor, i suggest to introduce if/unless conditions on comand line args :
exec executable=git
arg value=commit/
arg line=-a if=${commit.all.files}/
arg value=-m/
arg value=${commit.message}/
/exec
I have a working implementation with related tests and documentation.
Commandline.Arg class now extends ProjectComponent, and expose accessors
for if/unless condition, and rely on PropertyHelper to check conditions.
Is this sufficient ? From what i have seen, it doesn't break backward
compatibility at least all tests are green :p.
The setProject(Project p) method should be invoked automatically by
ProjectHelper isn't it ?
If ant is used in pure java and we ommited invoking setProject(Project p)
method, it should also works as PropertyHelper seems null safe.
If there is no objection i will commit this this week end.
Re: Adding if/unless conditions on commandline args
+1
2013/5/3 Antoine Levy Lambert anto...@gmx.de
I wonder whether we could not add if an unless on all nested elements in
the framework ?
Regards,
Antoine
On May 3, 2013, at 2:57 AM, Jean-Louis Boudart wrote:
Hi,
It's currently difficult to make reusable script when using exec task
or
any other task using commandline args.
We oftenly need some dynamic arguments and this can be complicated.
Therefor, i suggest to introduce if/unless conditions on comand line
args :
exec executable=git
arg value=commit/
arg line=-a if=${commit.all.files}/
arg value=-m/
arg value=${commit.message}/
/exec
I have a working implementation with related tests and documentation.
Commandline.Arg class now extends ProjectComponent, and expose accessors
for if/unless condition, and rely on PropertyHelper to check conditions.
Is this sufficient ? From what i have seen, it doesn't break backward
compatibility at least all tests are green :p.
The setProject(Project p) method should be invoked automatically by
ProjectHelper isn't it ?
If ant is used in pure java and we ommited invoking setProject(Project p)
method, it should also works as PropertyHelper seems null safe.
If there is no objection i will commit this this week end.
-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
--
Jean Louis Boudart
Independent consultant
Apache EasyAnt commiter http://ant.apache.org/easyant/
Re: Adding if/unless conditions on commandline args
By the way i don't know yet where we can plugin tests on if/unless
condition in this case.
2013/5/3 Jean-Louis Boudart jeanlouis.boud...@gmail.com
+1
2013/5/3 Antoine Levy Lambert anto...@gmx.de
I wonder whether we could not add if an unless on all nested elements in
the framework ?
Regards,
Antoine
On May 3, 2013, at 2:57 AM, Jean-Louis Boudart wrote:
Hi,
It's currently difficult to make reusable script when using exec task
or
any other task using commandline args.
We oftenly need some dynamic arguments and this can be complicated.
Therefor, i suggest to introduce if/unless conditions on comand line
args :
exec executable=git
arg value=commit/
arg line=-a if=${commit.all.files}/
arg value=-m/
arg value=${commit.message}/
/exec
I have a working implementation with related tests and documentation.
Commandline.Arg class now extends ProjectComponent, and expose accessors
for if/unless condition, and rely on PropertyHelper to check conditions.
Is this sufficient ? From what i have seen, it doesn't break backward
compatibility at least all tests are green :p.
The setProject(Project p) method should be invoked automatically by
ProjectHelper isn't it ?
If ant is used in pure java and we ommited invoking setProject(Project
p)
method, it should also works as PropertyHelper seems null safe.
If there is no objection i will commit this this week end.
-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
--
Jean Louis Boudart
Independent consultant
Apache EasyAnt commiter http://ant.apache.org/easyant/
--
Jean Louis Boudart
Independent consultant
Apache EasyAnt commiter http://ant.apache.org/easyant/
Re: Evaluating Bintray as a distribution platform for easyant plugins
No objections either if both Apache non Apache plugins are on bintray ? :p 2013/5/3 Jan Matèrne (jhm) apa...@materne.de Neither from me. My objections were for ASF plugins not for outside ASF ;) Jan -Ursprüngliche Nachricht- Von: Antoine Levy Lambert [mailto:anto...@gmx.de] Gesendet: Freitag, 3. Mai 2013 10:06 An: Ant Developers List Betreff: Re: Evaluating Bintray as a distribution platform for easyant plugins Hello Jean-Louis, I was not aware of bintray, I have just looked at the web site. No objections from me. Regards, Antoine On May 3, 2013, at 2:14 AM, Jean-Louis Boudart wrote: No objections? :p Le 29 avr. 2013 20:59, Jean-Louis Boudart jeanlouis.boud...@gmail.com a écrit : Here is the original thread from easyant-dev ML during apache incubation : http://markmail.org/thread/uv2xkj63rkdh2thh Le 29 avr. 2013 20:53, Jean-Louis Boudart jeanlouis.boud...@gmail.com a écrit : I would prefer having the artifacts on ASF servers. A (Nexus based) repository is at https://repository.apache.org/ Ant + Ivy are available at https://repository.apache.org/content/repositories/releases/ I would also prefer this but will ASF authorize non apache project (read plugins with incompatible licences for example) to publish there ? I don't think so. By the way you really got the idea, have one connection point to ease understanding for the community. That's why we intially setup a online repository (repo.easyant.org) with two internal repository : * one for apache plugins * one for non apache plugins (the one having potential issues with licenses like sonar or checkstyle) I was suggesting to reproduce this on bintray. If this could be done @ASF i would definitively go in that direction ! But is this really possible ? As bintray and github supports Markdown syntax, i made some experimentation on plugin documentation generation. Are you writing the markdown by hand or do you generate that from java source? Generated through easyant plugin report task ( http://svn.apache.org/repos/asf/ant/easyant/plugins/trunk/easyant- pl ugin-documentation/src/main/resources/easyant-report-mardown.xsl) with a custom xsl ( http://svn.apache.org/repos/asf/ant/easyant/plugins/trunk/easyant- pl ugin-documentation/src/main/resources/easyant-report-mardown.xsl ) Result on github : https://github.com/easyant/sonar-easyant- plugin Result on bintray : https://bintray.com/pkg/show/readmore/easyant/community- plugins/sona r- easyant-plugin On BinTray the tables are broken. No syntax highlighting on BT? I also reported this. Git support is growing at ASF, e.g. Camel is on the migration path from svn to git. A blocker to their vote is https://issues.apache.org/jira/browse/INFRA-6197 Nice to know :). I was talking here for non apache plugins/ - 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 -- Jean Louis Boudart Independent consultant Apache EasyAnt commiter http://ant.apache.org/easyant/
Re: Evaluating Bintray as a distribution platform for easyant plugins
Let's first define a few things. We need to distribute many things : - easyant distribution itself (shipping ivy, ant and easyant-core.jar itself). As the entry point of easyant it remains natural to be distributed through dist.apache.org - additionnal task we may write in future. If we produce external ant task it make sense to distribute them through maven central to be reused outside of easyant context - plugins / buildtypes / skeletons are extension of easyant providing ready to use stuff. Now let's focus on plugins/buildtypes and skeletons: Existing *plugins* are plain xml build script (example of junit plugin [1]) . They only make sense in easyant context, and are not packaged as jars. Some plugins may provide additionnal files (properties, xml, etc...). In a near future we could imagine having plugins / buildtypes written with other languages (ie. ant javafront, groovyfront, antdsl). A *buildtype* is a superpset of plugins providing a lifecycle with a set of ready to use plugins. *Skeletons* are similar to maven archetypes (ie. templates of projects). Plugins, buildtypes and skeletons have their own release lifecycle. We could for example release intermediary release of junit plugin without recreating a new easyant distribution. As easyant is based on ivy we have many options to publish / resolve. To leverage standard plugins (the basic one to make java projects) we could ship them in easyant distribution (this was done through a JarResolver [2] in our first release :)). If you download 0.9 artifacts should be retrieved stuff from easyant-core.jar itself except if you use more recent plugins (or ones not included in the distribution). We may have in future plugins that couldn't be hosted as ASF as they may have incompatible licenses. It's for example the case for chekstyle/sonar plugins. It would be easier if have *one entry point* for users. That's why we created http://repository.easyant.org. Then we could isolate apache plugins from external ones by having two internal repositories : - http://repository.easyant.org/apache-easyant/ - http://repository.easyant.org/community-easyant/ The same can be done on bintray with a better reliability. I don't think maven central is a good host for easyant plugins. Publishing with a m2compatible layout sounds limiting to me as it quickly force us to play with classifier when we have many artifacts. Note that maven central / repository.apache.org only distribute .jar files. On both you MUST provide a pom.xml which doesn't make sense for us. How i imagine things ? 1. EasyAnt plugins / buildtypes / skeletons should be released on public repositories individually. 2. Public repository will become main references to distribute/fetch internal stuff for easyant (plugins,buildtypes, skeletons). 3. Single *entry point* for users even if we may have two internal repositories to distinguish apache artifacts from community ones 4. Public repository may provide a simple way to browse/search existing stuff. 5. When a new easyant distribution is created we should ship a set of plugins in the distribution itself by copying them from public repository (the reference :)) I would add two extra requirements for public repository : 1. Plugins / buildtypes documentation should be accessible closed to artifacts (can be done through readmore files on bintray [3]) 2. It should provide download statistics [1] https://svn.apache.org/repos/asf/ant/easyant/plugins/trunk/junit/src/main/resources/junit.ant [2] http://ant.apache.org/ivy/history/latest-milestone/resolver/jar.html [3] https://bintray.com/pkg/show/readmore/easyant/community-plugins/sonar-easyant-plugin 2013/5/6 Antoine Levy Lambert anto...@gmx.de No objections from me. Antoine On May 3, 2013, at 6:04 AM, Jean-Louis Boudart wrote: No objections either if both Apache non Apache plugins are on bintray ? :p 2013/5/3 Jan Matèrne (jhm) apa...@materne.de Neither from me. My objections were for ASF plugins not for outside ASF ;) Jan -Ursprüngliche Nachricht- Von: Antoine Levy Lambert [mailto:anto...@gmx.de] Gesendet: Freitag, 3. Mai 2013 10:06 An: Ant Developers List Betreff: Re: Evaluating Bintray as a distribution platform for easyant plugins Hello Jean-Louis, I was not aware of bintray, I have just looked at the web site. No objections from me. Regards, Antoine On May 3, 2013, at 2:14 AM, Jean-Louis Boudart wrote: No objections? :p Le 29 avr. 2013 20:59, Jean-Louis Boudart jeanlouis.boud...@gmail.com a écrit : Here is the original thread from easyant-dev ML during apache incubation : http://markmail.org/thread/uv2xkj63rkdh2thh Le 29 avr. 2013 20:53, Jean-Louis Boudart jeanlouis.boud...@gmail.com a écrit : I would prefer having the artifacts on ASF servers. A (Nexus based) repository is at https://repository.apache.org/ Ant + Ivy
Re: Adding if/unless conditions on commandline args
I'm not a big fan of adding this feature through internal namespaces, was
there any complication to do it without namespaces ?
Anyway it does the job, and stuff looks extensible so i'm fine with current
solution if no one objects.
49036 add 'unless' attribute to JUnit test element was already solved
isn't it ?
2013/5/6 Peter Reilly peter.kitt.rei...@gmail.com
wow, I had forgot about that!
Peter
On Mon, May 6, 2013 at 12:55 AM, Antoine Levy Lambert anto...@gmx.de
wrote:
Hi,
I have committed a patch created by Peter Reilly back in 2007.
The bugzilla PR is 43362 [1]
If the community is happy with this change we will be able to close a
number of bug reports requesting if/unless on various elements .
For instance 49136 requesting if/unless support for attribute nested
element of manifest task,
49036 add 'unless' attribute to JUnit test element,
...
Regards,
Antoine
[1] https://issues.apache.org/bugzilla/show_bug.cgi?id=43362
On May 3, 2013, at 5:37 AM, Jan Matèrne (jhm) wrote:
AFAIK this was discussed several times in the past (few years) with the
result, that having if/unless an _all_ elements would decrease
maintainability of the build scripts.
But +1 from me for having if/unless on nested elements.
What about supporting more complex conditions via nested condition
elements?
Jan
-Ursprüngliche Nachricht-
Von: Michael Clarke [mailto:michael.m.cla...@gmail.com]
Gesendet: Freitag, 3. Mai 2013 11:01
An: Ant Developers List
Betreff: Re: Adding if/unless conditions on commandline args
+1 from me too
On 3 May 2013, at 09:37, Jean-Louis Boudart
jeanlouis.boud...@gmail.com wrote:
+1
2013/5/3 Antoine Levy Lambert anto...@gmx.de
I wonder whether we could not add if an unless on all nested
elements
in the framework ?
Regards,
Antoine
On May 3, 2013, at 2:57 AM, Jean-Louis Boudart wrote:
Hi,
It's currently difficult to make reusable script when using exec
task
or
any other task using commandline args.
We oftenly need some dynamic arguments and this can be
complicated.
Therefor, i suggest to introduce if/unless conditions on comand
line
args :
exec executable=git
arg value=commit/
arg line=-a if=${commit.all.files}/ arg value=-m/ arg
value=${commit.message}/ /exec
I have a working implementation with related tests and
documentation.
Commandline.Arg class now extends ProjectComponent, and expose
accessors for if/unless condition, and rely on PropertyHelper to
check conditions.
Is this sufficient ? From what i have seen, it doesn't break
backward compatibility at least all tests are green :p.
The setProject(Project p) method should be invoked automatically
by ProjectHelper isn't it ?
If ant is used in pure java and we ommited invoking
setProject(Project p) method, it should also works as
PropertyHelper seems null safe.
If there is no objection i will commit this this week end.
-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For
additional
commands, e-mail: dev-h...@ant.apache.org
--
Jean Louis Boudart
Independent consultant
Apache EasyAnt commiter http://ant.apache.org/easyant/
-
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
--
Jean Louis Boudart
Independent consultant
Apache EasyAnt commiter http://ant.apache.org/easyant/
Re: [VOTE] Ant 1.9.1 Release
+1 2013/5/16 Antoine Levy Lambert anto...@gmx.de Hi, I have uploaded candidate artefacts for an ant 1.9.1 release to : http://people.apache.org/~antoine/dist Let's vote on releasing these. Let's start with my own +1. Regards, Antoine - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org -- Jean Louis Boudart Independent consultant Apache EasyAnt commiter http://ant.apache.org/easyant/
Re: Check available updates for libs in ivy
Hi, As far as i know there is no quick way to do this yet. As this feature is also neededi have spend a couple of hours on it yesterday. I have a something working and i would be able to commit it soon. Basically it's a new ant task. The task try to resolve all libs with a configurable revision (latest.release) by default and log : - dependency updates - new transitive dependencies - missing transitive dependencies (in case you upgrade a dependency and one of it's dependency disappear you rely on a new version) The task will be a post resolve task [1], so all commons attributes would be available including inline=true :p. As mentioned before you will be able to change the revision to check so if you want to see potential updates including integration revision you could do something like : ivy:displaydependencyupdate revisiontocheck=latest.integration/ Would this cover your need ? [1] http://ant.apache.org/ivy/history/latest-milestone/use/postresolvetask.html PS: the name of the task and attributes is not the final one :p if you have a better idea you're welcome 2013/6/3 Mykhailo Oleksiuk mykhailo.oleks...@gmail.com Hi, Unfortunately I didn't get response from ivy-user group. Dev guys, could you help me with my question? Is it possible to get list of libs that are not up-to-date in quick way(ivy command/script/ant task etc)? Thanks, Mykhailo. -- Forwarded message -- From: Mykhailo Oleksiuk mykhailo.oleks...@gmail.com Date: Tue, May 28, 2013 at 10:09 AM Subject: Check available updates for libs in ivy To: ivy-u...@ant.apache.org Hi, We have a big project with 100+ libs defined in ivy.xml. Is it possible to get list of libs that are not up-to-date in quick way(ivy command/script/ant task etc)? -- Regards, Mykhailo Oleksiuk. -- Regards, Mykhailo Oleksiuk. -- Jean Louis Boudart Independent consultant Apache EasyAnt commiter http://ant.apache.org/easyant/
Re: Cutting a Release because of the Javadoc Vulnerability?
+1 2013/7/6 Matt Benson gudnabr...@gmail.com Sounds like a good idea. Thanks Stefan! Matt On Jul 5, 2013 9:36 AM, Stefan Bodewig bode...@apache.org wrote: Hi all, as you most probably know Oracle's javadoc tool prior to Java 7u25 creates javadocs with a frame injection vulnerability - see CVE-2013-1571, VU#225657 for details. The javadoc task in trunk contains a patch based on code by Uwe Schindler of the Lucene community that postprocesses javadoc's output, identifies vulnerable pages and fixes them. This is similar to the patch applied to Maven's javadoc plugin which led to their version 2.9.1. Do we want to cut an Ant release to help Ant users to get around the vulnerability or is the macrodef I've added to the online manual enough in our view? If enough people think we should cut a release then I guess I'm volunteering to be the RM. Stefan - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org -- Jean Louis Boudart Independent consultant Apache EasyAnt commiter http://ant.apache.org/easyant/
Re: [VOTE] Release Ant 1.9.2
+1 2013/7/9 Stefan Bodewig bode...@apache.org Hi all, a very small release with some bugfixes in addition to the workaround for Oracle's javadoc vulnerability. I propose to adopt the following as Ant 1.9.2 SVN tag: http://svn.apache.org/repos/asf/ant/core/tags/ANT_192/ revision 1500831 Tarballs: https://dist.apache.org/repos/dist/dev/ant/ revision 2394 Maven Artifacts: https://repository.apache.org/content/repositories/orgapacheant-116/org/apache/ant/ Vote will be open for about 72 hours Cheers Stefan - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org -- Jean Louis Boudart Independent consultant Apache EasyAnt commiter http://ant.apache.org/easyant/
Easyant - Plugin conflict management
Hi there, It becomes necesssary to manage conflicts between plugins. This issues has been raised many time and is referenced on jira[1]. Currently easyant offers import task taking some specific attributes to resolve a plugin (mainly organisation, module name and revision). ea:import org=mycompany module=myplugin revision=x.x/ This task will : * resolve the given plugin or buildtypr * create a dynamic classpath for this plugin * expose location of others extra files through properties (ex checkstyle.xml containing checkstyle rules, this files is shipped in the plugin). Thoses properties will then be reused by the plugin itself * import the real ant file (invoke the importTask from ant core under the hood) This task is currently used : * dynamically by easyant to load system plugins (skeletons for example) * dynamically by easyant when you specify ea:build or ea:plugin tags in module.ivy files * invoked in plugin ant file itselfs * invoked in module.ant if users has complex needs Additionnal there is two alliases for this task to import plugins and buildtype. ea:plugin module=compile-java revision=0.9/ ea:plugin module=build-std-java revision=0.9/ If organisation attribute is not specified on aliases default one will be used. It does the job but it doesn't handle conflict between plugins. Some plugins relies on abstract ones. Exemple: package-jar depends on abstract-package, abstract-package depends on abstract-compile, but compile-java plugin also depends on abstract-compile. Which versi of abstract-compile will be taken in case both plugins load different version ? The answer is the first one ! This becomes more problematic on buildtypes, as buildtypes loads a set of plugins (including themself others abstract-plugins). Ok so now you should have a quick picture of the problem. What could be done ? We can rely on ivy to describe dependency on plugins. But then how could we know in which order plugins should be loaded ? I suggest to introduce a deferred import mechanism. We should split responsibility in two distinct steps. 1 - resolve (based on ivy) the whole graph of plugins and store the resolve report somewhere as a reusable reference in ant project 2 - invoke a new import task should import already resolved plugins (the task could rely on the report stored as a reference in ant project) Exemple : compile java will have an ivy dependency on abstract-compile dependency org=org.apache.easyant.plugins module=abstract-compile revision=1.0/ The compile java ant script will import the resolved plugin ea:import-deferred org=org.apache.easyant.plugins module=abstract-compile/ Note that i'm not fixed yet with the task name. Any suggestion (even for alliases are welcome). To maintain backward compatibility i'm in favor of creating new aliases import-plugin and import-buildtype instead of reusing existing ones. People would be able to continue using existing task with known the limitation (no conflict management on plugins). This can help if someone wants to load plugins in module.ant after setting a few properties. I also recommend adding a warning on existing task to recommend people using the new import mechanism. What do you think ?ea [1] https://issues.apache.org/jira/browse/EASYANT-13 -- Jean Louis Boudart Independent consultant Apache EasyAnt commiter http://ant.apache.org/easyant/
Re: Easyant - Plugin conflict management
I've commited changes on trunk with some unit tests if you want to have a look. Known limitation : * system plugins doesn't participate *yet* to global plugin resolution * plugins classpath created dinamically will all contains the whole resolution graph (not really a problem) Point 1 : this can even affect performance. Invoking resolve process one time seems much more speed that invoking plugins individually. Point 2 : Even if there is no much activity, i suggest to keep backward compatibility Point 3 : By two steps i meant running a global resolve (for all plugins and buildtypes including transitive ones). And then have a second class invoked to perform individual import of ant build file by picking them from the ResolveReport. You can check ResolvePlugins and ImportDeferred class in trunk if you want to see concrete stuff. 2013/8/17 Nicolas Lalevée nicolas.lale...@hibnet.org Long overdue response. Le 3 août 2013 à 13:33, Jean-Louis Boudart jeanlouis.boud...@gmail.com a écrit : Hi there, It becomes necesssary to manage conflicts between plugins. This issues has been raised many time and is referenced on jira[1]. Currently easyant offers import task taking some specific attributes to resolve a plugin (mainly organisation, module name and revision). ea:import org=mycompany module=myplugin revision=x.x/ This task will : * resolve the given plugin or buildtypr * create a dynamic classpath for this plugin * expose location of others extra files through properties (ex checkstyle.xml containing checkstyle rules, this files is shipped in the plugin). Thoses properties will then be reused by the plugin itself * import the real ant file (invoke the importTask from ant core under the hood) This task is currently used : * dynamically by easyant to load system plugins (skeletons for example) * dynamically by easyant when you specify ea:build or ea:plugin tags in module.ivy files * invoked in plugin ant file itselfs * invoked in module.ant if users has complex needs Additionnal there is two alliases for this task to import plugins and buildtype. ea:plugin module=compile-java revision=0.9/ ea:plugin module=build-std-java revision=0.9/ If organisation attribute is not specified on aliases default one will be used. It does the job but it doesn't handle conflict between plugins. Some plugins relies on abstract ones. Exemple: package-jar depends on abstract-package, abstract-package depends on abstract-compile, but compile-java plugin also depends on abstract-compile. Which versi of abstract-compile will be taken in case both plugins load different version ? The answer is the first one ! This becomes more problematic on buildtypes, as buildtypes loads a set of plugins (including themself others abstract-plugins). Ok so now you should have a quick picture of the problem. What could be done ? We can rely on ivy to describe dependency on plugins. But then how could we know in which order plugins should be loaded ? I suggest to introduce a deferred import mechanism. We should split responsibility in two distinct steps. 1 - resolve (based on ivy) the whole graph of plugins and store the resolve report somewhere as a reusable reference in ant project 2 - invoke a new import task should import already resolved plugins (the task could rely on the report stored as a reference in ant project) Exemple : compile java will have an ivy dependency on abstract-compile dependency org=org.apache.easyant.plugins module=abstract-compile revision=1.0/ The compile java ant script will import the resolved plugin ea:import-deferred org=org.apache.easyant.plugins module=abstract-compile/ Note that i'm not fixed yet with the task name. Any suggestion (even for alliases are welcome). To maintain backward compatibility i'm in favor of creating new aliases import-plugin and import-buildtype instead of reusing existing ones. People would be able to continue using existing task with known the limitation (no conflict management on plugins). This can help if someone wants to load plugins in module.ant after setting a few properties. I also recommend adding a warning on existing task to recommend people using the new import mechanism. What do you think ? I see 3 points here. First, managing plugin dependencies: with Ivy, of course, we couldn't agree more :) Then about creating new tasks to keep backward compatibility. I think we can break backward compatibility. Easyant is not yet 1.0 and I do not see much activity on the user list. I would prefer bugging the current users than having an error-prone and deprecated task around. Third there is the resolve in two steps. I really like the idea. I am not sure though if we need this in order to bring conflict management in plugin dependencies. And I am not sure how far you are willing to go. Actually
Re: Easyant - Plugin conflict management
My answers below 2013/8/26 Dridi Boukelmoune dridi.boukelmo...@zenika.com Point 2 : Even if there is no much activity, i suggest to keep backward compatibility fine for me. Not necessary from my point of view. My only advice is to avoid legacy (or technical debt ;) at such early time. I was suggesting to keep backward compatibility mainly because easyant is build by easyant :). Though we need older plugins to build the new easyant and vice et versa. Point 3 : By two steps i meant running a global resolve (for all plugins and buildtypes including transitive ones). And then have a second class invoked to perform individual import of ant build file by picking them from the ResolveReport. ok I see. This make totally sense. This is where I'm lost. Actually the whole issue of dependencies conflicts between plugins. Here is the behavior I think I've observed with Maven: - maven resolves project dependencies and does a shitty job at conflicts resolution - maven resolves plugins dependencies one by one and downloads them lazily - each plugin is executed with its own classloader, and doesn't care about other plugins dependencies - I can get a dozen versions of the infamous[1] plexus-utils in a single build My point is, given proper isolation, is it a real issue to have different plugins depending on different versions of the same modules ? The main point is to avoid having dozen version of jars :). But we also have a internal limitation, ant doesn't load a buildfile two times. So if we have many plugins relying on abstract ones, abstract ones must be uniquely resolved. -- Jean Louis Boudart Independent consultant Apache EasyAnt commiter http://ant.apache.org/easyant/
Re: Java version of Ivy/IvyDE
So what do you think ? [ ] we should continue to support Java 1.4 [ ] we should make Ivy and IvyDE require Java 5 [x] we should make Ivy and IvyDE require Java 6 -- Jean Louis Boudart http://ant.apache.org/easyant/
Re: [VOTE] Release of IvyDE 2.2.0.final
Sorry of the delay. Here is my +1 tested on a few projects without particular issues. 2013/11/19 Antoine Levy Lambert anto...@gmx.de +1 from me too, good work Nicolas, Antoine On Nov 10, 2013, at 3:25 PM, Nicolas Lalevée wrote: Le 10 nov. 2013 à 10:15, Stefan Bodewig bode...@apache.org a écrit : On 2013-11-09, Nicolas Lalevée wrote: The tag is here: http://svn.apache.org/repos/asf/ant/ivy/ivyde/tags/2.2.0.final/ You can download the distribution from this URL: https://dist.apache.org/repos/dist/dev/ant/ivyde/2.2.0.final/ as usual, I won't pretend I could judge the release based on content. hashes and signatures are good, source tarball matches the tag. +1 for the release as is. One small nit, two files contain $Date$ sequences which svn likes to expand based on the current locale, you may want to remove those variables from doc/screenshot-projects/commons-httpclient-3.0/src/java/org/apache/commons/httpclient/HttpStatus.java and TestHttpStatus.java. Cleaned up. org.apache.ivyde.eclipse.resolvevisualizer/src/org/apache/ivyde/eclipse/resolvevisualizer/Plugin.java is missing the license header, this really should be fixed. Indeed. I have updated the release doc to do a last check of the RAT report, which I should have done. Thanks ! Nicolas - 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 -- Jean Louis Boudart Independent consultant Apache EasyAnt commiter http://ant.apache.org/easyant/
Re: [VOTE] Charles Duffy as a committer
+1 2013/11/23 Stefan Bodewig bode...@apache.org On 2013-11-22, Antoine Levy-Lambert wrote: I would like to nominate Charles Duffy as a committer. Charles has proposed a number of patches to Ivy such as IVY-1421, IVY-1423, IVY-1424 and recently a patch concerning the useorigin attribute for the case of URL resources which happen to be files. +1 Stefan - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org -- Jean Louis Boudart Independent consultant Apache EasyAnt commiter http://ant.apache.org/easyant/
Re: [RESULT][VOTE] Jean-Louis Boudart as a PMC member
Thanks guys ! 2013/12/3 Nicolas Lalevée nicolas.lale...@hibnet.org I count 7 binding +1. The vote pass. Welcome to the Ant PMC Jean-Louis ! Nicolas Le 26 nov. 2013 à 12:04, Nicolas Lalevée nicolas.lale...@hibnet.org a écrit : Jean-Louis has been around for a very long time, owned committership, contributed a lot to bring EasyAnt into the Ant PMC, and he is participating to the vote in the release process. Thus, let's invite Jean-Louis to be part of the PMC. Here is my +1. Nicolas - 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 -- Jean Louis Boudart Independent consultant Apache EasyAnt commiter http://ant.apache.org/easyant/
