Unable to build 3.4-SNAPSHOT since a few days

[Benjamin Lerman]

Hi,



Since a few days, I cannot build the 3.4-SNAPSHOT anymore.



The error is in /metafacades/uml/emf/uml2



The build log is:



http://www.ambre.net/misc/andromda-build-log



It seems that it needs a dependency to

Code: Select all

 <groupId>org.eclipse.emf</groupId>
 <artifactId>common</artifactId>
 <version>2.1.0</version>


--

Benjamin

[Bob Fields]

That dependency is in the andromda maven repository, see http://team.andromda.org/maven2/org/eclipse/emf/common/2.1.0/.



Is your maven configuration pointing to that repository for updates?



You should see an error like 'attempting to download XXX' and 'Could not find in any repository' with the list of repositories searched.

[Benjamin Lerman]

That dependency is in the andromda maven repository, see http://team.andromda.org/maven2/org/eclipse/emf/common/2.1.0/.

Is your maven configuration pointing to that repository for updates?

You should see an error like 'attempting to download XXX' and 'Could not find in any repository' with the list of repositories searched.

I did join the build log. The problem is not about finding the jar, the problem is that this jar is not declared in the pom.xml

[Bob Fields]

Tracing the dependency from the metafacades/emf/uml2 pom:



uml2 depends on org.eclipse.uml2 1.1.1

which depends on

org.eclipse.emf.ecore 2.1.0

which depends on

org.eclipse.emf.common 2.1.0



so the dependency does not have to be added again to the uml2 pom.



It builds just fine on the andromda server with this dependency hierarchy - does your local dependency hierarchy look different?

[Bob Fields]

BTW the group/artifact name was changed to conform to the naming convention used in many other repositories (i.e. fornax, ibiblio). Unfortunately, some repositories have a screwed up version of the eclipse artifacts (bad dependency version ranges yields no dependent versions able to be found). You may need to delete or rename your org/eclipse directory in your local repository and download the artifacts again from team.andromda.org to get the dependencies right. I did this in preparation for adding the UML2 2.x support with a whole new set of EMF/UML2 versions.

[Benjamin Lerman]

Tracing the dependency from the metafacades/emf/uml2 pom:

uml2 depends on org.eclipse.uml2 1.1.1
which depends on
org.eclipse.emf.ecore 2.1.0
which depends on
org.eclipse.emf.common 2.1.0

so the dependency does not have to be added again to the uml2 pom.

It builds just fine on the andromda server with this dependency hierarchy - does your local dependency hierarchy look different?

Do you use maven1 or maven2?



With maven2, I have:

Code: Select all

mvn dependency:tree ->

[INFO] [dependency:tree]
[INFO] org.andromda.metafacades:andromda-metafacades-emf-uml2:xml.zip:3.4-SNAPSHOT
[INFO] +- commons-lang:commons-lang:jar:2.3:compile
[INFO] +- junit:junit:jar:3.8.1:test
[INFO] +- org.eclipse:uml2:jar:1.1.1:compile
[INFO] |  +- org.eclipse.emf:ecore:jar:2.1.0:compile
[INFO] |  +- org.eclipse.emf.ecore:xmi:jar:2.1.0:compile
[INFO] |  +- org.eclipse.uml2:common:jar:1.1.1:compile
[INFO] |  - org.eclipse.emf.mapping:ecore2xml:jar:2.2.0:compile
[INFO] +- commons-collections:commons-collections:jar:3.1:compile
[INFO] +- org.andromda:andromda-core:jar:3.4-SNAPSHOT:compile
[INFO] |  +- commons-digester:commons-digester:jar:1.7:compile
[INFO] |  |  +- commons-beanutils:commons-beanutils:jar:1.7.0:compile
[INFO] |  |  +- commons-logging:commons-logging:jar:1.1:compile
[INFO] |  |  - xml-apis:xml-apis:jar:1.0.b2:compile
[INFO] |  +- log4j:log4j:jar:1.2.12:compile
[INFO] |  +- xalan:xalan:jar:2.7.0:runtime
[INFO] |  - xerces:xercesImpl:jar:2.6.0:runtime
[INFO] +- org.andromda.profiles.uml14:andromda-profile:xml.zip:3.4-SNAPSHOT:runtime
[INFO] |  +- org.andromda.profiles.uml14:andromda-profile-datatype:xml.zip:3.4-SNAPSHOT:runtime
[INFO] |  +- org.andromda.profiles.uml14:andromda-profile-webservice:xml.zip:3.4-SNAPSHOT:runtime
[INFO] |  +- org.andromda.profiles.uml14:andromda-profile-service:xml.zip:3.4-SNAPSHOT:runtime
[INFO] |  +- org.andromda.profiles.uml14:andromda-profile-process:xml.zip:3.4-SNAPSHOT:runtime
[INFO] |  +- org.andromda.profiles.uml14:andromda-profile-meta:xml.zip:3.4-SNAPSHOT:runtime
[INFO] |  +- org.andromda.profiles.uml14:andromda-profile-messaging:xml.zip:3.4-SNAPSHOT:runtime
[INFO] |  +- org.andromda.profiles.uml14:andromda-profile-xml:xml.zip:3.4-SNAPSHOT:runtime
[INFO] |  +- org.andromda.profiles.uml14:andromda-profile-persistence:xml.zip:3.4-SNAPSHOT:runtime
[INFO] |  - org.andromda.profiles.uml14:andromda-profile-presentation:xml.zip:3.4-SNAPSHOT:runtime
[INFO] +- org.eclipse.uml2:resources:jar:1.1.0:compile
[INFO] +- org.andromda.metafacades:andromda-metafacades-uml:jar:3.4-SNAPSHOT:compile
[INFO] +- org.andromda.translationlibraries:andromda-ocl-translation-core:jar:3.4-SNAPSHOT:compile
[INFO] +- org.andromda.translationlibraries:andromda-ocl-validation-library:jar:3.4-SNAPSHOT:compile
[INFO] - org.andromda:andromda-utils:jar:3.4-SNAPSHOT:compile
[INFO]    - commons-io:commons-io:jar:1.4:compile
[INFO] ------------------------------------------------------------------------


As you can see, the version of org.eclipse.uml2:common is 1.1.1, not 2.1.0

[Bob Fields]

Your org.eclipse.emf.ecore pom is different than the one from the team.andromda repository, that one has a dependency on the emf.common 2.1.0. Unfortunately, there is no 'standard' dependency for these artifacts, since the 'master' on ibiblio is screwed up, various repositories (including andromda) went their own way with naming conventions and versions and dependencies for the org.eclipse artifacts. It wouldn't hurt anything in the current source tree to add this additional dependency to the uml2 metafacade, so it will be compatible with fornax and many other repositories, since we can't assume the downloaded artifacts will always come from team.andromda. You can delete/rename your local org/eclipse/emf/ecore directory and download the new one from andromda, or add the new dependency locally to metafacades/emf/uml2, or wait until the pom.xml is updated in the andromda3 source tree (shortly).



uml2.common 1.1.1 is the correct dependency in both places, I think you meant to say emf.common instead. We use maven2 for everything.

Code: Select all

[INFO] +- org.eclipse:uml2:jar:1.1.1:compile
[INFO] |  +- org.eclipse.emf:ecore:jar:2.1.0:compile
[INFO] |  |  - org.eclipse.emf:common:jar:2.1.0:compile
[INFO] |  +- org.eclipse.emf.ecore:xmi:jar:2.1.0:compile
[INFO] |  +- org.eclipse.uml2:common:jar:1.1.1:compile
[INFO] |  - org.eclipse.emf.mapping:ecore2xml:jar:2.2.0:compile
[INFO] +- org.eclipse.uml2:resources:jar:1.1.0:compile

[Benjamin Lerman]

Your org.eclipse.emf.ecore pom is different than the one from the team.andromda repository, that one has a dependency on the emf.common 2.1.0. Unfortunately, there is no 'standard' dependency for these artifacts, since the 'master' on ibiblio is screwed up, various repositories (including andromda) went their own way with naming conventions and versions and dependencies for the org.eclipse artifacts. It wouldn't hurt anything in the current source tree to add this additional dependency to the uml2 metafacade, so it will be compatible with fornax and many other repositories, since we can't assume the downloaded artifacts will always come from team.andromda. You can delete/rename your local org/eclipse/emf/ecore directory and download the new one from andromda, or add the new dependency locally to metafacades/emf/uml2, or wait until the pom.xml is updated in the andromda3 source tree (shortly).

uml2.common 1.1.1 is the correct dependency in both places, I think you meant to say emf.common instead. We use maven2 for everything.

Yes, I meant emf.common



Now, there is something that I do not understand. You say that andromda team had to repackage the artifact because central one was screwed up. Ok, no problem with that, but then you must change the version number and (for example) suffix it with as custom value. Otherwise there is 2 different artifacts with the same groupId/artifactId/version and depending on the environment (in fact whether the first looked repository is andromda or central) you will get different results. This is quite bad for build reproductivity.



The other solution is to use a dependencyManagement session in the poms to set the version of the used artifact. Then you do not even need to publish the jar.

[Bob Fields]

This is an external dependency from Eclipse, I have no control over the version numbering and would not want to rename artifacts or diverge versions from ones already released by eclipse.org, I wouldn't presume to create a point release of their same artifacts with no changes just to fix the dependency management within maven. The fix within andromda is to make our dependencies match the ones on other more well-known sites (other than ibiblio) with working dependency versions and ranges, and to add the additional dependency to metafacades-uml. This dependency was just a miss on my part when I assembled the ecore pom in the andromda maven repository.

[Bob Fields]

The ecore dependencies in the external andromda maven repository have been fixed to match those of other repositories.