Hypothetically there were two software companies, A & B. Both companies have about a couple of hundred Eclipse projects. Both have a few application end-products. Each end-product project has a dependency different from the others.
A relies on maven for dependency management. It practices code freezing and therefore decouples projects from each other and hence is able to mavenize dependencies.
B relies on Eclipse Subversive plugin. For any particular end-product project, all projects it depends on will be checked out of SVN and included in the Eclipse project build path. If a project has dependencies on 50 projects, all 50 projects will be subject to source code modification and that is why they do not use Maven.
The two companies merged into AB. The desire is to have a maven like dependency management that would also work on SVN repositories. That is, the hypothetical POM should be able to specify either jar dependency (company A style) or SVN source-code dependency (company B style). If the dependency is a jar, it should pull the dependency from the repository into the developer's workstation's maven cache. If the dependency is source code in SVN, it should check it out into the SVN working directory.
How should company AB proceed with their vision unifying the two build attitudes, technologically? I specify "technologically" to avert answers that would deal with micromanaging or modifying the philosophical attitudes of developers of the merged company.
Would Gradle be of any help? If so, how and why? What other alternatives?
Presumably the projects that company B created create packaged (jar) products as part of their delivery/build. If this is the case, then company AB could create their own artifact repository (my company uses Artifactory) and the projects from company B could be manually (or automatically) added to that repository as versioned releases or as snapshots. Then company A projects could specify their dependencies as jar dependencies and pull from artifactory.
For projects that are deeply dependent and frequently edited concurrently I'd suggest making them sub-projects of one root project.
None of my suggestions above require the use of Gradle, but Gradle makes much of this easy to implement.
svn:externals are a technical solution. Then educate the developers abusing svn that Maven dependencies are less worse.
Related
i have a scala js sbt project, i developped in this project new user interface components.
the person p1 has a project with the same structure (same build.properties & plugins.sbt), how can he access to my user interface components.
Should i add some specification in build.sbt ?
If you want to share some project settings, you can create a sbt plugin - it will allow you to have some common settings, add dependencies to other sbt plugins and even override their configuration. See for example sbt-softwaremill as a example of plugin that is used to share some commons between projects.
It won't magically update all configs, because:
build.properties is evaluated before the sbt code is run
you have to add this plugin to plugins.sbt
you have to create project structure in each project
Any more config sharing than that is theoretically possible by e.g. using git submodules and commiting symlinks to repo, but that would be pretty wrong - any change to one project would result in a change in another project, and you have them separated for a reason - if both projects were the same you would have one project in the first place.
And if you are need to share the code itself, you can build the code, publish it to an artifactory and add dependency in another project.
But that's only if you really have two projects, and it's entirely possible that you just need to have one git project with different branches, where ever developer would work on their own branch and then merge changes to common branch, bacause that's the point of using git.
This may be a stupid and easy question but I don't know. I'm working (with other people too) on java projects (java maven projects) with Eclipse and SVN.
When I commit my changes, do I just need to commit the *.java files I changed or the whole java Maven project ?
Thank you
In general, it is a good idea to ask your team for common rules or best practice. So if they want you to only change *.java files, you are better off to contribute only changes that respect this requirement.
In most SW-teams or companies, however, a project is not only made from plain source code. Many projects are composed of .properties files, XML-based configuration, e.g. Maven's project and module definitions found in pom.xml files, or even things like SQL-snippets that is shared for development purposes. From time to time, a developer needs to conduct changes to these non-*.java files. So it might get "blocking" if you would't share these adjustments with your team via a common repository, i.e. here: git or svn.
In essence, ask your team what they expect from you as a contributor OR let your team discuss and make a decision on how you want to organise the project and the code repository on a file level.
Edit: Beware of hidden directories with local configuration information, i.e. the IDE-environment such as properties of the local workspace. These are clearly developer specific things.
Hope it helps.
I would guess a clean might either delete jars from the repo or leave it untouched. But when I manually deleted the existing repo and then cleaned all the existing projects in Eclipse, the repository was recreated. The problem at least is that it takes a long time. So I am firstly curious as to why this behavior occurs and secondly wonder if there is a way not to have this occur.
The maven install is really little more than a bootstrap. All maven actions are implemented as plugins, downloaded from a Maven repository, and cached in the local repository. This architecture makes Maven extremely extensible (if you know what you're doing).
To improve build performance you are best advised to setup a local Maven repository manager. This will cache jars that would otherwise have to be downloaded from Maven Central.
Running a Maven repository manager is not hard nowadays. It offers the additional features of providing a place to manage dependencies that may not be available from a remote repo and as a place to share jars between different project builds.
The clean phase of the clean lifecycle does not clean your local repository. Instead, it does "remove all files generated by the previous build" (in your project's target directory, if you use Maven's Standard Directory Layout). See Introduction to the Build Lifecycle, Lifecycle Reference, Clean Lifecycle.
The "Why?" is answered by Mark O'Connor.
The answer to "How to avoid?" is: Don't delete your local repo completely.
You can delete sub-directories of libraries/artifacts you once tried out or tested but decided to abandon using them without any impact, though.
I am currently trying to find out how the Ivy workflow would be when generating VC tags (We're using SVN, but it doesn't matter).
The thing is, we have developed multiple libraries that depend on each other. To ease development, the dependency tag within ivy.xmlhas the attribute rev set to latest.integration.
<dependencies>
<dependency org="my-company" name="my-lib" rev="latest.integration"/>
</dependencies>
It was actually the result form this question on StackOverflow. This helps so that we can make changes quickly in one library and that run unit test in our main application without the need to manually change the revision.
Once the development is done, we publish the libs to out internal shared Ivy repository and create an SVN tag.
The problem that arises is that once we need to rebuild the software from a tag Ivy still points to latest.integration which, at a later point in time, will most probably point to a another integration build, maybe even to a later published version (depending on the resolver config).
Now that question is obvious: what is the best way to have Ivy to resolve to the published revisions that were integration.latest at the time the VCS tag was created. And it would be very helpful if the answer is not "enter published revisions by hand before you create the tag". Maybe I need to add something to my ANT build script, maybe some changes in my settings.xml or ivy.xml.
Since Ivy is quite a smart and handy little tool, I guess there must be a way to do it...
The ivy deliver task is used to create a resolved ivy file from the project's original. By "resolved" I mean a file fit to be published into a remote repository. This means not only are the dynamic dependencies resolved, the optional revision and status attributes are set in the module's info tag.
The following example creates an ivy.xml file in the build directory:
<ivy:deliver deliverpattern="${build.dir}/ivy.xml" pubrevision="${project.version}" status="release"/>
Check the file you'll discover the dependency versions are set.
At this point it is worth noting that this ability is one of subtle but important points that separates ivy from Maven. Ivy allows your automated release system to simply create tag and run the build. Take a look at the convoluted steps required by Maven and automated by it's release plugin :
Check that there are no uncommitted changes in the sources
Check that there are no SNAPSHOT dependencies
Change the version in the POMs from x-SNAPSHOT to a new version (you will be prompted for the versions to use)
Transform the SCM information in the POM to include the final destination of the tag
Run the project tests against the modified POMs to confirm everything is in working order
Commit the modified POMs
Tag the code in the SCM with a version name (this will be prompted for)
Bump the version in the POMs to a new value y-SNAPSHOT (these values will also be prompted for)
Commit the modified POMs
Count carefully.... That's 2 commits and a tag operation..... All because Maven's module version is mandatory and we're trying to capture in the SCM the resolved dependencies....
So, my advise is to be wary of emulating Maven. When I tag my code I capture a point in time, when I built the code. I rely on the fact that the ivy file pushed to my remote repository is fully resolved. The truly paranoid could of course keep a local copy of this ivy file, but it would never be the file that was used to build the original. In practice it's never possible to truly reproduce the original binary, just something that approximates to it.
Additional info
To help understand how the deliver task is used, the following examples show how it's used to create resolved Maven POM files when publishing ANT artefacts into a Maven repository like Nexus:
Convert ivy.xml to pom.xml
Automate ivy revision increase for all my projects using ant script
Our company develop several software products, which reuse each others packages (we use Java). Every product represented as separate Eclipse Java project and has it's own versioning repository (we use Mercurial).
When we find a bug in some shared package, we need to transfer changes to all consuming projects, and this is a hell. The key problem is that Eclipse project can be associated only with one versioning repository.
Could someone recommend some way to associate Eclipse Java project whith several versioning repositories which in ideal may be geterogeious (svn, git, mercurial) ?
This should really be addressed with:
git submodules or
mercurial SubRepos
You can modify directly from a submodule/subrepo, push to a "central" repo, and other can fetch the modifications, and then go one directory up (in the main repo referencing all the other submodules) in order to register the new commit of the new submodule/subrepo state.
The "main project" (the main repo which record all the other submodules/subrepos states) is not necessary an Eclipse project (one of the submodules can be the main Eclipse project, with project dependencies on other).
See "true nature of submodules" for more on that process, which remains "not easy", but can still be managed precisely.