[m2] Artifact tasks transitive dep issues

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

[m2] Artifact tasks transitive dep issues

Nicola Ken Barozzi

I'm using the Ant tasks from m2-a2 to download and use jars for Cocoon.

The transitive dependency is giving me some issues:

1 - I don't know which jars get downloaded simply as a result of a
     transitive dependency.
     Something like the below suggestion would help.

                   - ~ -

   Downloading: xxy/xxy-impl/1.0/xxy-impl-1.0.jar

   Referenced by:
     > pom
   + > xyz  (suggested 0.9)
   - > xddz (suggested 1.1)

   Transferring 128K

                   - ~ -

   Downloading: xdy/xdy-impl/1.1/xdy-impl-1.1.jar

   Referenced by:
     > pom

   Transferring 12K

                   - ~ -

   Downloading: xeey/xeey-impl/1.0/xeey-impl-1.0.jar

   Referenced by:
   - > xddz (suggested 1.1)

   Transferring 19K

                   - ~ -

2 - I specified *xercesImpl* 2.6.2 but it also downloaded *xerces* 1.6.3
     as a result of a transitive dependency.
     There could be some kind of link that points the xerces requests
     done by the transitive dep system to the newer artifacts.

3 - I specified ant *1.6.5* and got ant-*optional-1.5.1* as an extra
     dependency because of a transitive dependency on another jar.
     This is similar to the above problem, only that I would now have to
     get more jars instead of the old 1.5.1 which has been split.

As a temporary solution to the above two problems, one could manually
specify which jars *not* to download. In this way I could block the
xerces and ant-optional jars and add the needed ones by hand.

Not exactly practical, but usable.

TIA

--
Nicola Ken Barozzi                   [hidden email]
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------

<?xml version="1.0" encoding="utf-16"?>
<project name="ccocoon-classpath" default="classpath"
xmlns:artifact="antlib:org.apache.maven.artifact.ant">
  <description>Autogenerated Ant build file that creates the
  classpath.</description>
  <target name="classpath">
    <artifact:dependencies pathId="dependency.classpath">
      <dependency groupId="ant" artifactId="ant" version="1.6.5" />
      <dependency groupId="ant-contrib" artifactId="ant-contrib"
      version="20020829" />
      <dependency groupId="xml-apis" artifactId="xml-apis"
      version="2.0.2" />
      <dependency groupId="xerces" artifactId="xercesImpl"
      version="2.6.2" />
      <!--endorsed/xalan-2.6.1-dev-20041008T0304.jar-->
      <dependency groupId="xml-resolver" artifactId="xml-resolver"
      version="1.1" />
      <dependency groupId="avalon-framework"
      artifactId="avalon-framework-api" version="4.1.5" />
      <!--Skipping avalon-framework-legacy-->
      <dependency groupId="avalon-framework"
      artifactId="avalon-framework-impl" version="4.1.5" />
      <!--Skipping excalibur-legacy-->
      <dependency groupId="excalibur-i18n"
      artifactId="excalibur-i18n" version="1.1" />
      <dependency groupId="excalibur-instrument"
      artifactId="excalibur-instrument" version="1.0" />
      <dependency groupId="excalibur-sourceresolve"
      artifactId="excalibur-sourceresolve" version="1.1" />
      <dependency groupId="excalibur-xmlutil"
      artifactId="excalibur-xmlutil" version="1.0" />
      <dependency groupId="excalibur-store"
      artifactId="excalibur-store" version="1.0" />
      <dependency groupId="excalibur-pool"
      artifactId="excalibur-pool-api" version="2.0" />
      <dependency groupId="excalibur-pool"
      artifactId="excalibur-pool-impl" version="2.0" />
      <dependency groupId="excalibur-pool"
      artifactId="excalibur-pool-instrumented" version="2.0" />
      <dependency groupId="excalibur-logger"
      artifactId="excalibur-logger" version="1.1" />
      <dependency groupId="regexp" artifactId="regexp"
      version="1.3" />
      <dependency groupId="servletapi" artifactId="servletapi"
      version="2.3" />
      <!--core/jcs-1.2.5-dev-20050313.jar-->
      <dependency groupId="commons-cli" artifactId="commons-cli"
      version="1.0" />
      <dependency groupId="commons-httpclient"
      artifactId="commons-httpclient" version="2.0.2" />
      <dependency groupId="commons-collections"
      artifactId="commons-collections" version="3.1" />
      <dependency groupId="commons-jexl" artifactId="commons-jexl"
      version="1.0" />
      <dependency groupId="commons-jxpath"
      artifactId="commons-jxpath" version="1.2" />
      <!--core/commons-lang-2.0-20041007T2305.jar-->
      <!--core/log4j-1.2.9.jar-->
      <!--core/rhino-1.6R1.jar-->
      <dependency groupId="ehcache" artifactId="ehcache"
      version="1.1" />
      <!--Skipping jing-->
      <dependency groupId="junit" artifactId="junit"
      version="3.8.1" />
      <dependency groupId="jmock" artifactId="jmock"
      version="1.0.1" />
      <dependency groupId="easymock" artifactId="easymock"
      version="1.1" />
      <dependency groupId="concurrent" artifactId="concurrent"
      version="1.3.4" />
      <dependency groupId="xmlunit" artifactId="xmlunit"
      version="0.8" />
      <dependency groupId="qdox" artifactId="qdox" version="1.5" />
    </artifact:dependencies>
    <path id="local.classpath">
      <path location="lib/endorsed/xalan-2.6.1-dev-20041008T0304.jar" />
      <path location="lib/core/jcs-1.2.5-dev-20050313.jar" />
      <path location="lib/core/commons-lang-2.0-20041007T2305.jar" />
      <path location="lib/core/log4j-1.2.9.jar" />
      <path location="lib/core/rhino-1.6R1.jar" />
    </path>
    <path id="classpath">
      <path refid="dependency.classpath" />
      <path refid="local.classpath" />
    </path>
  </target>
</project>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [m2] Artifact tasks transitive dep issues

Brett Porter
On 6/7/05, Nicola Ken Barozzi <[hidden email]> wrote:

> 1 - I don't know which jars get downloaded simply as a result of a
>      transitive dependency.
>      Something like the below suggestion would help.
>
>                    - ~ -
>
>    Downloading: xxy/xxy-impl/1.0/xxy-impl-1.0.jar
>
>    Referenced by:
>      > pom
>    + > xyz  (suggested 0.9)
>    - > xddz (suggested 1.1)

Something like that is definitely the plan, though looking at JIRA, I
don't see it specifically. I had intended to do this along with the
refactoring of the code to support version ranges.

> 2 - I specified *xercesImpl* 2.6.2 but it also downloaded *xerces* 1.6.3
>      as a result of a transitive dependency.
>      There could be some kind of link that points the xerces requests
>      done by the transitive dep system to the newer artifacts.

Naming amiguities are something we will need to sort out, for sure. I
had a "supersedes" tag noted in JIRA, but that and specification
dependencies are looking like v2.1 features at this point. As you also
list, there needs to be some tracking of the history of the artifact
identifiers to avoid conflicts.

For the current implementation, manual exclusions will be necessary.

> As a temporary solution to the above two problems, one could manually
> specify which jars *not* to download. In this way I could block the
> xerces and ant-optional jars and add the needed ones by hand.

Just implemented it in m2 and working on the ant tasks as we speak.
Will be doing that and plenty of work on the ant tasks over the next
few days. If you want to track dev at all, we plan a release in 2
weeks so you can have a date when it is generally available.

Thanks for the feedback.

Cheers,
Brett

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [m2] Artifact tasks transitive dep issues

Nicola Ken Barozzi
Brett Porter wrote:
> On 6/7/05, Nicola Ken Barozzi <[hidden email]> wrote:
...
>>As a temporary solution to the above two problems, one could manually
>>specify which jars *not* to download.
...
> Just implemented it in m2 and working on the ant tasks as we speak.

Great!

> Will be doing that and plenty of work on the ant tasks over the next
> few days.
...

I would like to eventually contribute to the Maven Ant tasks, but before
I need to get a hang of it. Sorry for the dumb question, but what do I
need to download-build-look-at to be able to work on the Maven Ant tasks?

> Thanks for the feedback.

Thanks for your efforts :-)

BTW, IMHO I would simply get rid of the current iteration of the tasks
and require a pom for declaring dependencies. Taking part in the
transitive dependency mechanism requires a pom, so why not build it
right away?

I would also like to use the POM from Ant to get some values, but it's
another topic ;-)

--
Nicola Ken Barozzi                   [hidden email]
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [m2] Artifact tasks transitive dep issues

Trygve Laugstøl-2
On Tue, Jun 07, 2005 at 07:18:06PM +0200, Nicola Ken Barozzi wrote:

> Brett Porter wrote:
> >On 6/7/05, Nicola Ken Barozzi <[hidden email]> wrote:
> ...
> >>As a temporary solution to the above two problems, one could manually
> >>specify which jars *not* to download.
> ...
> >Just implemented it in m2 and working on the ant tasks as we speak.
>
> Great!
>
> >Will be doing that and plenty of work on the ant tasks over the next
> >few days.
> ...
>
> I would like to eventually contribute to the Maven Ant tasks, but before
> I need to get a hang of it. Sorry for the dumb question, but what do I
> need to download-build-look-at to be able to work on the Maven Ant tasks?
 $ svn co https://svn.apache.org/repos/asf/maven/components/trunk maven-2
 $ cd maven-2
 $ sh m2-bootstrap-all.sh
 

> >Thanks for the feedback.
>
> Thanks for your efforts :-)
>
> BTW, IMHO I would simply get rid of the current iteration of the tasks
> and require a pom for declaring dependencies. Taking part in the
> transitive dependency mechanism requires a pom, so why not build it
> right away?
>
> I would also like to use the POM from Ant to get some values, but it's
> another topic ;-)
Already in progress!

http://jira.codehaus.org/browse/MNG-435

>
> --
> Nicola Ken Barozzi                   [hidden email]
>             - verba volant, scripta manent -
>    (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [m2] Artifact tasks transitive dep issues

Brett Porter
On 6/8/05, Trygve Laugstøl <[hidden email]> wrote:
> > I would like to eventually contribute to the Maven Ant tasks, but before
> > I need to get a hang of it. Sorry for the dumb question, but what do I
> > need to download-build-look-at to be able to work on the Maven Ant tasks?
>
>  $ svn co https://svn.apache.org/repos/asf/maven/components/trunk maven-2
>  $ cd maven-2
>  $ sh m2-bootstrap-all.sh

This won't actually build the ant tasks. The reason this step is given
is that the ant tasks build with m2, and I've recently started using a
feature newer than alpha-2, so you need to bootstrap the latest code.

From there maven-artifact-ant will build with:
m2 package assembly:assembly
(this will eventually be reduced to just the latter command).

Alternatively, you can just use package, and include all the
dependencies in the classpath for ant as well.

> > BTW, IMHO I would simply get rid of the current iteration of the tasks
> > and require a pom for declaring dependencies. Taking part in the
> > transitive dependency mechanism requires a pom, so why not build it
> > right away?
> >
> > I would also like to use the POM from Ant to get some values, but it's
> > another topic ;-)
>
> Already in progress!
>
> http://jira.codehaus.org/browse/MNG-435
>

Yep, I'm working on that now. I expected that some users will only
download and not upload, and may not want to interact with a pom file,
but I think it should definitely be encouraged.

Cheers,
Brett

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]