You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Steve Loughran <st...@apache.org> on 2005/05/05 12:44:15 UTC
and m2
I've been busy last week reworking the <libraries> stuff to handle
maven2 stuff.
to be precise, it now has the notion of a <layout> which can dictate the
client side or server side layout of libraries, and <transports>
independent from the layout
<repository>
<urltransport urls="some url list">
<flatdirectorylayout>
</repository>
<repository>
<mcasttransport port="8193" address="240.4.4.1"> //hypothetical
<maven2layout>
</repository>
Some of the tests are passing, some are failing. But I'm not happy with
what I've done. Its complex and still potentially quite brittle. There
is still a lot of extra maven2 support in a special repository, to get
.pom and .md5 files, and it gets very convoluted trying to decouple
local and remote naming policies. This is resulting code that is
over-complex, hard to test, and potentially hard to maintain.
At the same time, I've been playing with the M2 artifact tasks. They
still need some work
-NPE if you omit an artifact
-minimially documented (e.g. how to set up ports)
But they work. And they work on Ant1.6.x *today*. And the antlib
declaration mechanism does work
I am thinking of stopping all work on <libraries>, embracing the maven2
stuff instead. Here is my rationale
-projects can start using the maven2 tasks today.
-the m2 stuff can implement transitive dependencies (if not already done)
-maybe even PGP validation (which needs bouncy castle jar)
-and maybe httpclient over the fairly brittle java.net code
-we avoid duplicating effort, introducing inconsistencies.
-ability to update outside the ant dev schedule
All the code in our SCM tree is russels' and mine, and while I am never
happy about deleting stuff I've worked on, I'm happier doing that than
maintaining something that is essentially duplicate work. All we get
from putting it in Ant is having something that is built in from the
outset -which is kind of useful for a bootstrap process. That's it,
really. Oh, and we can make some explicit tweaks to <java> to
incorporate it inline.
Here is my proposal
-check in what I have so far
-tag it
-delete it
-scrub it from the 1,7 requirements list.
-embrace it where appropriate as the preferred way to do dynamic
library download
-identify and fix areas where the tasks can improve; get those patches in
-identify where Ant can be made to work better with the tasks. One
thing that Russell identified was a need to get the classpath into the
<lib> element of a WAR, for example. An extra element in <zip> could do
that, and we could maybe add fileset creation to the m2 tasks alongside
their path facility.
Sometimes you just need to knife the baby
-steve
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: and m2
Posted by Steve Loughran <st...@apache.org>.
Nicola Ken Barozzi wrote:
> For what it's worth, I agree 100%.
>
> BTW, I have proposed that Cocoon uses the m2 task for jar handling, and
> the vote has passed.
makes sense
>
>> Sometimes you just need to knife the baby
>
>
> Sad, but true.
>
> In any case, your work will be of great help in giving a hand to Maven's
> artifact handling.
>
We actually have JAR download from M2 repositories in SmartFrog
(product placement 3.04.022 is now out :
http://sourceforge.net/project/showfiles.php?group_id=87384&package_id=108447&release_id=323559
)
this lets you write and deploy templates that pull down files from the
repository, here, for example, is a declaration of how to download,
validate and run Axis TCPmon:
sfConfig extends Compound {
library extends Maven2Library {
}
commons-logging extends JarArtifact {
library LAZY PARENT:library;
project "commons-logging";
version "1.0.4";
sha1 "f029a2aefe2b3e1517573c580f948caac31b1056";
md5 "8a507817b28077e0478add944c64586a";
}
axis extends JarArtifact {
library LAZY PARENT:library;
project "axis";
version "1.1";
sha1 "edd84c96eac48d4167bca4f45e7d36dcf36cf871";
}
tcpmonitor extends Java {
classname "org.apache.axis.utils.tcpmon";
classpath [
LAZY axis:absolutePath,
LAZY commons-logging:absolutePath];
}
}
This is shipping in the beta, but will evolve as we use it.
Interestingly, it makes the language work as a language for describing
what to run -the only barrier being the perennial problem of all the Sun
JARs not being up for dynamic download.
-steve
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: and m2
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Steve Loughran wrote:
>
> I've been busy last week reworking the <libraries> stuff to handle
> maven2 stuff.
>
> to be precise, it now has the notion of a <layout> which can dictate the
> client side or server side layout of libraries, and <transports>
> independent from the layout
...
In theory, it seems excellent, and it's conceptually more complete.
I'm happy that you have tried it.
...
> But I'm not happy with what I've done.
...
> This is resulting code that is over-complex, hard to test, and
> potentially hard to maintain.
Ruper, AKA Depot, used a complete package to resolve the versioning. It
was very complex, I can definately agree with you. It's complexity made
other developers not even touch the versioning code, and it was one of
the causes it stopped, IMHO.
> At the same time, I've been playing with the M2 artifact tasks. They
> still need some work
...
> But they work. And they work on Ant1.6.x *today*. And the antlib
> declaration mechanism does work
>
> I am thinking of stopping all work on <libraries>, embracing the maven2
> stuff instead. Here is my rationale
> -projects can start using the maven2 tasks today.
> -the m2 stuff can implement transitive dependencies (if not already done)
> -maybe even PGP validation (which needs bouncy castle jar)
> -and maybe httpclient over the fairly brittle java.net code
> -we avoid duplicating effort, introducing inconsistencies.
> -ability to update outside the ant dev schedule
Very reasonable.
> All the code in our SCM tree is russels' and mine, and while I am never
> happy about deleting stuff I've worked on, I'm happier doing that than
> maintaining something that is essentially duplicate work.
Been there, done that.
ant <get> -> Ruper -> Depot -> *clunck* -> trashcan
> Here is my proposal
> -check in what I have so far
> -tag it
> -delete it
> -scrub it from the 1,7 requirements list.
> -embrace it where appropriate as the preferred way to do dynamic
> library download
> -identify and fix areas where the tasks can improve; get those patches in
> -identify where Ant can be made to work better with the tasks. One
> thing that Russell identified was a need to get the classpath into the
> <lib> element of a WAR, for example. An extra element in <zip> could do
> that, and we could maybe add fileset creation to the m2 tasks alongside
> their path facility.
For what it's worth, I agree 100%.
BTW, I have proposed that Cocoon uses the m2 task for jar handling, and
the vote has passed.
> Sometimes you just need to knife the baby
Sad, but true.
In any case, your work will be of great help in giving a hand to Maven's
artifact handling.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: and m2
Posted by Steve Loughran <st...@apache.org>.
Brett Porter wrote:
> (bringing over to maven dev as Steve suggested)
>
> On 5/19/05, Steve Loughran <st...@apache.org> wrote:
>
>>A key issue w/ transitive dependencies is that I may not want a library,
>>just because it was used in a library I want. Certainly I need the right
>>to override versions. This is why dependency declarations in JAR file
>>manifests is so broken; the builder of the jar is telling the deployer
>>what files they MUST use, not what files they SHOULD use.
>
>
> Right - this is the direction we are pushing. To get dependencies to
> specify the versions they recommend, but because we still have
> "nearest wins", you always get to veto that if necessary.
>
>
>>One thing I've felt might be good in dependency declarations (or in the
>>POM) would be for something to declare what well-known-APIs they
>>implement. So that if one version of JAX-RPC is declared, you don't need
>>another.
>
>
> http://docs.codehaus.org/display/MAVEN/specification+dependencies
got it. yes, JAXP is the case in point. you dont care what people built
against, as long as it is the same version of the spec. Maybe projects
need to declare they were built against an API for xml, just like
commons-logging-api.
> In my mind it was bettter to leave this for a later Maven 2.1 feature
> release, after we were confident with the versioning aspects of normal
> dependencies, because this adds an extra level of complexity on top of
> that. And a lot of specifications have found their way into the JDK so
> become specified explicitly less.
yes, it is just that I cant currently import Xom, for example, because
it pulls in jaxen which pulls in dom4j. I now have a private release
with a dependency-free POM in my local cache.
>
>>Maybe the version policy could be pluggable
>>
>>policy=none //no transitiveness
>> newest-wins //newest matters
>> nearest-wins //closest declaration matters
>> fail //fail on conflict
>>
>>though I think I'm mixing policy of transitive on/off with conflict
>>resolution here. hmm.
>
> yeah, I think they are separate. the rest sound like the conflict
> strategies I'd envisage. There may be others as well (eg, deploying to
> a particular appserver, so make sure you get version X of all these
> because they'll be forced on you).
aah, and then there are endorsed directories, worst case of all 'we know
better' overrides.
>
> I'm not sure "no transitiveness" is a good idea. I think it's
> something that once available, people will use as the quick fix to a
> problem rather than figuring out a real cause, and miss an opportunity
> to improve the overall quality of the data. Which would be ironic,
> given how long people asked for transitive deps - to turn it off so
> quickly - but I knew that it would come because as you said earlier,
> version management isn't a trivial problem. If you are the one
> building the libraries, it requires discipline to keep compatibility,
> consistent naming, etc.
>
> I'd prefer to be able to filter out unwanted dependencies as an
> alternative to turning it off.
yes, a block would work.
>
>
>>I've just subscribed to maven dev; I will discuss it there.
>
>
> welcome :) I've been planning to take a pass at this design for
> alpha-3 tomorrow, so I'll reply to anything else in the morning.
ok. one more troublespot is that no pom should be a warning, not an
error. there are things on the site without poms, and it is easier to
pull third party libs in to shape without writing pom files. That said,
it'd be nice to have a set of .pom files to go with the various java
libraries, maybe even some client program to do the
retrieve/clickthrough/version-tag/save processing to bring them into the
repository structure.
-steve
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: and m2
Posted by Brett Porter <br...@apache.org>.
Dan Diephouse wrote:
>
> Requiring the user to override/exclude dependencies in their pom
> somehow would be kind of a pain.
Ok, but the alternative is just to turn it off (still needing to be
specified), which I feel like is too much of an easy out. We're in early
days here, we can make the metadata get better. We do need to make it
simple though.
> But, what if m2 made it simple for a user to change this. Ie m2 would
> iterate through the dependency conflicts and allow you to select
> different options.
I don't feel like this type of prompting is appropriate in most cases,
especially for something as common as dependency resolution. I think we
should definitely have tools to help setup the previously mentioned
configurations though. What you are proposing sounds exactly like
http://deputy.sourceforge.net/
> I guess I'm just thinking how to make it easier for the user, because
> I believe that ease of entry will be a real barrier to use the way
> things are now.
>
I agree - though you have bitten off probably the hardest one of all
given all your sun spec dependencies :)
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: and m2
Posted by Dan Diephouse <da...@envoisolutions.com>.
Brett Porter wrote:
>I'm not sure "no transitiveness" is a good idea. I think it's
>something that once available, people will use as the quick fix to a
>problem rather than figuring out a real cause, and miss an opportunity
>to improve the overall quality of the data. Which would be ironic,
>given how long people asked for transitive deps - to turn it off so
>quickly - but I knew that it would come because as you said earlier,
>version management isn't a trivial problem. If you are the one
>building the libraries, it requires discipline to keep compatibility,
>consistent naming, etc.
>
>I'd prefer to be able to filter out unwanted dependencies as an
>alternative to turning it off.
>
I've been thinking about this because this annoys me a lot :-). As Steve
so excellently put it, a lot of times dependencies are a SHOULD not a
MUST. But transitive dependencies do give us a degree of power.
Requiring the user to override/exclude dependencies in their pom somehow
would be kind of a pain. But, what if m2 made it simple for a user to
change this. Ie m2 would iterate through the dependency conflicts and
allow you to select different options.
For example:
$ m2 dosomething
You have 3 different versions of xerces in your classpath. Please select
which one you would like to use:
(1) 2.4.1
(2) 2.6.0
(3) 2.6.2
> ?
One could imagine a similar interface which allowed users to exclude
dependencies from different child poms as well. It would then write out
the information to the pom or another file. Would this work for the ant
tasks too?
I guess I'm just thinking how to make it easier for the user, because I
believe that ease of entry will be a real barrier to use the way things
are now.
- Dan
--
Dan Diephouse
Envoi Solutions LLC
http://netzooid.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: and m2
Posted by Brett Porter <br...@gmail.com>.
(bringing over to maven dev as Steve suggested)
On 5/19/05, Steve Loughran <st...@apache.org> wrote:
> A key issue w/ transitive dependencies is that I may not want a library,
> just because it was used in a library I want. Certainly I need the right
> to override versions. This is why dependency declarations in JAR file
> manifests is so broken; the builder of the jar is telling the deployer
> what files they MUST use, not what files they SHOULD use.
Right - this is the direction we are pushing. To get dependencies to
specify the versions they recommend, but because we still have
"nearest wins", you always get to veto that if necessary.
> One thing I've felt might be good in dependency declarations (or in the
> POM) would be for something to declare what well-known-APIs they
> implement. So that if one version of JAX-RPC is declared, you don't need
> another.
http://docs.codehaus.org/display/MAVEN/specification+dependencies
In my mind it was bettter to leave this for a later Maven 2.1 feature
release, after we were confident with the versioning aspects of normal
dependencies, because this adds an extra level of complexity on top of
that. And a lot of specifications have found their way into the JDK so
become specified explicitly less.
> > The final project should use the most recent
> > version allowed by all of the definitions (on the assumption that the
> > most recent is backwards compatible and has less bugs than earlier
> > versions :)
>
> That's one assumption, but I take the view is that If I explicitly ask
> for an older version, I should get that (albeit maybe with a warning).
Absolutely. I was just suggesting an algorithm that would determine
the best version unaided, but when it comes down to it the final
project has to decide. In a lot of cases, an older version might work
just fine because several other projects have overstated their needs,
but a warning is still a good idea.
> Maybe the version policy could be pluggable
>
> policy=none //no transitiveness
> newest-wins //newest matters
> nearest-wins //closest declaration matters
> fail //fail on conflict
>
> though I think I'm mixing policy of transitive on/off with conflict
> resolution here. hmm.
yeah, I think they are separate. the rest sound like the conflict
strategies I'd envisage. There may be others as well (eg, deploying to
a particular appserver, so make sure you get version X of all these
because they'll be forced on you).
I'm not sure "no transitiveness" is a good idea. I think it's
something that once available, people will use as the quick fix to a
problem rather than figuring out a real cause, and miss an opportunity
to improve the overall quality of the data. Which would be ironic,
given how long people asked for transitive deps - to turn it off so
quickly - but I knew that it would come because as you said earlier,
version management isn't a trivial problem. If you are the one
building the libraries, it requires discipline to keep compatibility,
consistent naming, etc.
I'd prefer to be able to filter out unwanted dependencies as an
alternative to turning it off.
> I've just subscribed to maven dev; I will discuss it there.
welcome :) I've been planning to take a pass at this design for
alpha-3 tomorrow, so I'll reply to anything else in the morning.
Cheers,
Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: and m2
Posted by Steve Loughran <st...@apache.org>.
Brett Porter wrote:
> On 5/17/05, Dominique Devienne <dd...@gmail.com> wrote:
>
>>I've used a more lenient model for my transitive dependency. The exact
>>version used to build something is recorded, but which version of a
>>given dependency to use is left up to the client.
>
>
> This is pretty much what is in Maven (and the artifact tasks) at the
> moment. It uses the "nearest" definition for conflict resolution. So
> declaring in the POM of the current project can ensure a particular
> version, otherwise you'll get one at depth 1, etc.
>
>
>>A colleage proposed an interesting idea of using predicates to state
>>compatibility between components the different version of a component.
One thing we all have to remember is that versioning is something
neither the CS or software engineering community have solved. Upgrades
can cause problems. But on the plus side, given the absence of strict CS
notions of compatibility, we can build things that only work sometimes
and get away with it :)
1. there is no way to guarantee consistent behaviour across versions.
Languages with more declarative pre- and post- conditions can do more
internal validation; java could use asserts more if Java1.4 was the minimum.
2. it is not enough to have the right set of components, the system
configuration must match what is required.
3. in a distributed system, it is the state of the entire network that
defines the effective behaviour of a remote component.
4. what can you do then? Test, that is all.
A key issue w/ transitive dependencies is that I may not want a library,
just because it was used in a library I want. Certainly I need the right
to override versions. This is why dependency declarations in JAR file
manifests is so broken; the builder of the jar is telling the deployer
what files they MUST use, not what files they SHOULD use.
One thing I've felt might be good in dependency declarations (or in the
POM) would be for something to declare what well-known-APIs they
implement. So that if one version of JAX-RPC is declared, you don't need
another.
> What we have is pretty basic, and we're definitely looking to improve
> it with some other types of resolution, such as what you've described.
> Ideally, a project would declare the minimum version it needs to work
> (and if applicable, maximum - or perhaps even known incompatible
> versions in between). The final project should use the most recent
> version allowed by all of the definitions (on the assumption that the
> most recent is backwards compatible and has less bugs than earlier
> versions :)
That's one assumption, but I take the view is that If I explicitly ask
for an older version, I should get that (albeit maybe with a warning).
Maybe the version policy could be pluggable
policy=none //no transitiveness
newest-wins //newest matters
nearest-wins //closest declaration matters
fail //fail on conflict
though I think I'm mixing policy of transitive on/off with conflict
resolution here. hmm.
>
> Again, local definition of an explicit version will ensure you get
> what you ask for.
>
> This also has important consequences for making builds reproducible in
> the future, too - obviously if the version remains flexible at the
> point it is published then it might not be the same later on. There
> needs to be a point during QA where you can lock it down to a version.
>
> if you'd like to track the feature, http://jira.codehaus.org/browse/MNG-303
I've just subscribed to maven dev; I will discuss it there.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: and m2
Posted by Brett Porter <br...@gmail.com>.
On 5/17/05, Dominique Devienne <dd...@gmail.com> wrote:
> I've used a more lenient model for my transitive dependency. The exact
> version used to build something is recorded, but which version of a
> given dependency to use is left up to the client.
This is pretty much what is in Maven (and the artifact tasks) at the
moment. It uses the "nearest" definition for conflict resolution. So
declaring in the POM of the current project can ensure a particular
version, otherwise you'll get one at depth 1, etc.
> A colleage proposed an interesting idea of using predicates to state
> compatibility between components the different version of a component.
What we have is pretty basic, and we're definitely looking to improve
it with some other types of resolution, such as what you've described.
Ideally, a project would declare the minimum version it needs to work
(and if applicable, maximum - or perhaps even known incompatible
versions in between). The final project should use the most recent
version allowed by all of the definitions (on the assumption that the
most recent is backwards compatible and has less bugs than earlier
versions :)
Again, local definition of an explicit version will ensure you get
what you ask for.
This also has important consequences for making builds reproducible in
the future, too - obviously if the version remains flexible at the
point it is published then it might not be the same later on. There
needs to be a point during QA where you can lock it down to a version.
if you'd like to track the feature, http://jira.codehaus.org/browse/MNG-303
Cheers,
Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: and m2
Posted by Dominique Devienne <dd...@gmail.com>.
On 5/16/05, Steve Loughran <st...@apache.org> wrote:
> I think what is happening is that the maven dependency model does work
> if you live only in maven-land (that is, provide your own poms, only set
> up classpaths via the dependency declarations). In this world,
> dependency logic should be a lot better than the classic
> whatever-is-in-the-filesys classpath setup we know and use. But trying
> to merge the two hurts.
>
> There is some mention in the docs of a "scope" switch, which seems to
> control some of this, but doesn't have a "no-transitive-fetching"
> option, which is what we need. Without that, it is unusable in ant
> itself, which does not bode well for other projects. Indeed, I cant seem
> to use it any of the three I've tried as eventually this transitiveness
> hits a brick wall somewhere in the dependency chain of the various XML
> tools.
I've used a more lenient model for my transitive dependency. The exact
version used to build something is recorded, but which version of a
given dependency to use is left up to the client. By default, we
assume backward compatibility and take the latest of the dependency,
but it can be customized by dependency by the client itself. (we
actually break up the version in two: a CVS branch tag, and a build
number. We usually say use the latest build of a given branch).
How does Maven resolve conflicting dependency? A depends on B and C,
both depending on D, but B depends on D v1, when C depends on D v2? A
colleage proposed an interesting idea of using predicates to state
compatibility between components the different version of a component.
The predicates are embedded in the 'POM' of a released component. So D
v2 states being BC with D v1, and thus when getting the dependencies
for A, you get D v2. I need to implement his idea eventually. --DD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: and m2
Posted by Brett Porter <br...@gmail.com>.
> I have a couple more things to ask. Where should the discussion on the
> Maven Ant tasks take place IYO?
Probably users@maven.apache.org (dev@ is fine too if you are more
comfortable there). Thanks.
Cheers,
Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: and m2
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Brett Porter wrote:
> On 5/16/05, Steve Loughran <st...@apache.org> wrote:
>
>>Example: fetching commons-logging 1.04
>
> Hi Steve,
>
> I'm going to work through the issues you filed here.
Brett, I appreciate your help, but it's unfair to only rely on your
kindness and on you being on this list :-)
I have a couple more things to ask. Where should the discussion on the
Maven Ant tasks take place IYO?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: and m2
Posted by Brett Porter <br...@gmail.com>.
On 5/16/05, Steve Loughran <st...@apache.org> wrote:
> Example: fetching commons-logging 1.04
Hi Steve,
I'm going to work through the issues you filed here. We have planned
for the next release some filtering. Ideally, it shouldn't be needed,
but some projects will always build one bundle for you and let you
guess which bits need which dependencies, so the user needs full
control. There are definitely problems with some of the metadata -
particularly in commons, and unfortunately I didn't get a whole lot of
interest from commons developers at the time, so I'm fixing things
myself.
Aside from that, for commons-logging, I think you actually want
commons-logging-api which has no dependencies, right?
Cheers,
Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: and m2
Posted by Steve Loughran <st...@apache.org>.
Stefan Bodewig wrote:
> On Thu, 05 May 2005, Steve Loughran <st...@apache.org> wrote:
>
>
>>I am thinking of stopping all work on <libraries>, embracing the
>>maven2 stuff instead.
>
>
> Sounds reasonable if you can make it do everything you intended to do
> with <libraries>.
I am having mixed fun here. With a new <copypath> task I can extract the
path and copy it into any directory (with flattening). But what is
hurting me here is the tasks' belief that I need the dependencies that
jars were built against.
Example: fetching commons-logging 1.04
[artifact:dependencies] Downloading:
commons-logging/commons-logging/1.0.4/commons-logging-1.0.4.pom
[artifact:dependencies] Transferring 7K
[artifact:dependencies] Downloading:
commons-logging/commons-logging/1.0.4/commons-logging-1.0.4.pom.md5
[artifact:dependencies] Transferring 0K
[artifact:dependencies] Downloading:
avalon-framework/avalon-framework/4.1.3/avalon-framework-4.1.3.pom
[artifact:dependencies] Transferring 0K
[artifact:dependencies] Downloading:
avalon-framework/avalon-framework/4.1.3/avalon-framework-4.1.3.pom.md5
[artifact:dependencies] Transferring 0K
[artifact:dependencies] Downloading: junit/junit/3.7/junit-3.7.pom
[artifact:dependencies] Transferring 0K
[artifact:dependencies] Downloading: junit/junit/3.7/junit-3.7.pom.md5
[artifact:dependencies] Transferring 0K
[artifact:dependencies] Downloading: log4j/log4j/1.2.6/log4j-1.2.6.pom
[artifact:dependencies] Transferring 0K
[artifact:dependencies] Downloading: log4j/log4j/1.2.6/log4j-1.2.6.pom.md5
[artifact:dependencies] Transferring 0K
[artifact:dependencies] Downloading: logkit/logkit/1.0.1/logkit-1.0.1.pom
[artifact:dependencies] Transferring 0K
[artifact:dependencies] Downloading:
logkit/logkit/1.0.1/logkit-1.0.1.pom.md5
[artifact:dependencies] Transferring 0K
[artifact:dependencies] Downloading: logkit/logkit/1.0.1/logkit-1.0.1.jar
[artifact:dependencies] Transferring 70K
[artifact:dependencies] Downloading:
logkit/logkit/1.0.1/logkit-1.0.1.jar.md5
[artifact:dependencies] Transferring 0K
[artifact:dependencies] Downloading: log4j/log4j/1.2.6/log4j-1.2.6.jar
[artifact:dependencies] Transferring 342K
[artifact:dependencies] Downloading: log4j/log4j/1.2.6/log4j-1.2.6.jar.md5
[artifact:dependencies] Transferring 0K
[artifact:dependencies] Downloading: junit/junit/3.7/junit-3.7.jar
[artifact:dependencies] Transferring 114K
[artifact:dependencies] Downloading: junit/junit/3.7/junit-3.7.jar.md5
[artifact:dependencies] Transferring 0K
[artifact:dependencies] Downloading:
avalon-framework/avalon-framework/4.1.3/avalon-framework-4.1.3.jar
[artifact:dependencies] Transferring 62K
[artifact:dependencies] Downloading:
avalon-framework/avalon-framework/4.1.3/avalon-framework-4.1.3.jar.md5
[artifact:dependencies] Transferring 0K
At the end of this, I end up with log41.2.6 and junit.3.7. Which, when I
copy into ant_home/lib, (as they are on the path), means that older
versions of all the libraries come in. This is not what I want, and will
lead to much more pain.
I think what is happening is that the maven dependency model does work
if you live only in maven-land (that is, provide your own poms, only set
up classpaths via the dependency declarations). In this world,
dependency logic should be a lot better than the classic
whatever-is-in-the-filesys classpath setup we know and use. But trying
to merge the two hurts.
There is some mention in the docs of a "scope" switch, which seems to
control some of this, but doesn't have a "no-transitive-fetching"
option, which is what we need. Without that, it is unusable in ant
itself, which does not bode well for other projects. Indeed, I cant seem
to use it any of the three I've tried as eventually this transitiveness
hits a brick wall somewhere in the dependency chain of the various XML
tools.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: and m2
Posted by Stefan Bodewig <bo...@apache.org>.
On Thu, 05 May 2005, Steve Loughran <st...@apache.org> wrote:
> I am thinking of stopping all work on <libraries>, embracing the
> maven2 stuff instead.
Sounds reasonable if you can make it do everything you intended to do
with <libraries>.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: and m2
Posted by Steve Loughran <st...@apache.org>.
Brett Porter wrote:
> Hi Steve,
>
> On 5/5/05, Steve Loughran <st...@apache.org> wrote:
>
>>At the same time, I've been playing with the M2 artifact tasks. They
>>still need some work
>
>
> Yep, this is certainly true.
>
>
>> -NPE if you omit an artifact
>
>
> I'm not sure what you mean here exactly - bad ID on the dependencies?
If I declare a dependency and leave artifactID blank, I'd have expected
the groupID to be used as the artifactID, instead I get an NPE.
>
> Validation of the task parameters was something I was a bit lazy with
> when I put this together for the first go around.
>
> My particular concern is the current size of the library... I need to
> do some work to reduce the dependencies of the artifact library itself
> (which has been on the list a while, but since we're more in feature
> mode it has been left until the June release).
>
>
>>I am thinking of stopping all work on <libraries>, embracing the maven2
>>stuff instead. Here is my rationale
>> -projects can start using the maven2 tasks today.
>
>
> I think this is a good idea - I'm sure we can cover the requirements
> of both sets of users and spend the extra effort adding the nicer
> features and necessary polish.
It also lets me use it today in all my projects, even the stuff that
needs to run on ant1.6.2+
>
>> -the m2 stuff can implement transitive dependencies (if not already done)
>
>
> this already works, and we've got a few features planned to improve on
> this for the June release which we are just starting to get down on
> "paper" rather than in various people's heads :)
>
>
>> -maybe even PGP validation (which needs bouncy castle jar)
>
>
> yeah, I definitely would like to see that happening. Like the ant
> tasks themselves, it seems like something we've been talking about
> forever and never had that right opportunity.
>
>
>> -and maybe httpclient over the fairly brittle java.net code
>
>
> This is a change that can be made at runtime - we have both httpclient
> and URLConnection based providers for HTTP.
>
>
>> -ability to update outside the ant dev schedule
>
>
> What are your thoughts on the distribution of this? Continue from
> where it is in Maven, from Ant, or some other shared area? I guess
> there is a question applies to separate antlibs in general - would
> they also be bundled as optionals inside an Ant distribution, or is
> there some mechanism for getting and installing them?
I'm happy for them to be in maven, especially if there is shared code
with the rest of your stuff. One thing we dont have is an easy way to
download and install antlibs...
>
> Anyway, this sounds really good to me. Let me know if I can do
> anything to help.
>
> We've got a release coming up (though because the ant tasks cropped up
> mid cycle, it won't be a lot different this time around), but if there
> are any major gotchas that should be fixed before then, now would be a
> good time to fix them. I'll try and take a look at the validation in
> particular.
Do you have any tests for the tasks yet? That is something I can assist
with :)
-steve
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: and m2
Posted by Brett Porter <br...@gmail.com>.
On 5/6/05, Steve Loughran <st...@apache.org> wrote:
> I can see that. I can see that downloading jaxen fails because it wants
> to get dom4j, which lacks a pom
>
> http://www.ibiblio.org/maven2/dom4j/dom4j/1.5.2/
Ok, I'll find out why it wasn't parsing. We are trying to chase down
the bad data in there rather than invalidating it. If something doen't
specify a pom at all, then one will be created for it.
You mentioned omitting artifactID and having it be equal to groupID -
I'm not certain that shorthand is a good idea as we try to encourage
richer group names going forward. Stiil, it is convenient so might be
worthwhile with a warning.
> How do I (a) turn of transitiveness,
This is not possible in the current version. Has been requested
before... added to the list.
> and (b) find the documentation of
> the task.
http://maven.apache.org/maven2/ant-tasks.html
I suppose you are looking for something more reference like which
isn't there at present.
You are right in that we don't have tests for the tasks themselves
either. There is some for the underlying artifact code, though I'm not
particularly happy with the coverage and will endeavour to improve
that before adding the next round of features.
The code for the tasks is at
http://svn.apache.org/viewcvs.cgi/maven/components/trunk/maven-artifact-ant
If you want to gather a list of things like above I can take a sweep
at it tomorrow. For now, bed :)
Thanks for taking a look.
Cheers,
Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: and m2
Posted by Steve Loughran <st...@apache.org>.
Brett Porter wrote:
>
>> -the m2 stuff can implement transitive dependencies (if not already done)
>
>
> this already works, and we've got a few features planned to improve on
> this for the June release which we are just starting to get down on
> "paper" rather than in various people's heads :)
I can see that. I can see that downloading jaxen fails because it wants
to get dom4j, which lacks a pom
http://www.ibiblio.org/maven2/dom4j/dom4j/1.5.2/
How do I (a) turn of transitiveness, and (b) find the documentation of
the task.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: and m2
Posted by Brett Porter <br...@gmail.com>.
Hi Steve,
On 5/5/05, Steve Loughran <st...@apache.org> wrote:
>
> At the same time, I've been playing with the M2 artifact tasks. They
> still need some work
Yep, this is certainly true.
> -NPE if you omit an artifact
I'm not sure what you mean here exactly - bad ID on the dependencies?
Validation of the task parameters was something I was a bit lazy with
when I put this together for the first go around.
> But they work. And they work on Ant1.6.x *today*. And the antlib
> declaration mechanism does work
That seemed the simplest way to me. I'd be interested if there are any
good alternatives to this as well.
My particular concern is the current size of the library... I need to
do some work to reduce the dependencies of the artifact library itself
(which has been on the list a while, but since we're more in feature
mode it has been left until the June release).
> I am thinking of stopping all work on <libraries>, embracing the maven2
> stuff instead. Here is my rationale
> -projects can start using the maven2 tasks today.
I think this is a good idea - I'm sure we can cover the requirements
of both sets of users and spend the extra effort adding the nicer
features and necessary polish.
> -the m2 stuff can implement transitive dependencies (if not already done)
this already works, and we've got a few features planned to improve on
this for the June release which we are just starting to get down on
"paper" rather than in various people's heads :)
> -maybe even PGP validation (which needs bouncy castle jar)
yeah, I definitely would like to see that happening. Like the ant
tasks themselves, it seems like something we've been talking about
forever and never had that right opportunity.
> -and maybe httpclient over the fairly brittle java.net code
This is a change that can be made at runtime - we have both httpclient
and URLConnection based providers for HTTP.
> -ability to update outside the ant dev schedule
What are your thoughts on the distribution of this? Continue from
where it is in Maven, from Ant, or some other shared area? I guess
there is a question applies to separate antlibs in general - would
they also be bundled as optionals inside an Ant distribution, or is
there some mechanism for getting and installing them?
Anyway, this sounds really good to me. Let me know if I can do
anything to help.
We've got a release coming up (though because the ant tasks cropped up
mid cycle, it won't be a lot different this time around), but if there
are any major gotchas that should be fixed before then, now would be a
good time to fix them. I'll try and take a look at the validation in
particular.
Cheers,
Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org