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: Adding if/unless conditions on commandline args
The problem of not using namespaces is that they
would not be backward compatible. Also the attributes
are 'magic' and we already have 'id' as a magic attribute,
which makes task code hard to reason about.
Peter
p.s, I really hate xml namespaces!
On Thu, May 9, 2013 at 4:43 PM, Jean-Louis Boudart
jeanlouis.boud...@gmail.com wrote:
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/
AUTO: Carsten Pfeiffer ist außer Haus (Rückkehr am 13.05.2013)
Ich kehre zurück am 13.05.2013. In dringenden Fällen, kontaktieren Sie bitte ErwinpunktTrataratgebitpunktde oder TompunktKraussatgebitpunktde. Hinweis: Dies ist eine automatische Antwort auf Ihre Nachricht Re: Evaluating Bintray as a distribution platform for easyant plugins gesendet am 09.05.2013 17:33:52. Diese ist die einzige Benachrichtigung, die Sie empfangen werden, während diese Person abwesend ist. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Adding if/unless conditions on commandline args
Hi, I also figured out that if and unless prefix are not going to mask
potential if or unless attributes already existing in custom types or data
types. I was glad to see that the patch was still usable with little manual
work after so many years in Bugzilla.
I did not try to create an implementation without namespaces, no idea whether
this would be easy or not.
Antoine
Peter Reilly peter.kitt.rei...@gmail.com a écrit :
The problem of not using namespaces is that they
would not be backward compatible. Also the attributes
are 'magic' and we already have 'id' as a magic attribute,
which makes task code hard to reason about.
Peter
p.s, I really hate xml namespaces!
On Thu, May 9, 2013 at 4:43 PM, Jean-Louis Boudart
jeanlouis.boud...@gmail.com wrote:
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/
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
