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.
Related
I am not able to find an answer to this question: How is it possible to make an project dependend on a git project in Eclipse? I am only able to find answers on this topic for maven projects or jar files.
Specifically, i am trying to make my project dependent on this git project. I was able to import it Eclipse, the src folder and everything inside it is shown correctly.
But i am not able to add it as dependency to my project, simply because Eclipse does not show the project in its dialogs. How is one supposed to add such projects?
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
I have multiple projects. I want to create different maven repository paths for each project. Means, each project should point to different folder as maven repository (by default C:/Users/USERNAME/.m2 is used as repo).
I know that this may increase the download and same files if used in multiple projects will be downloaded/kept multiple times. But i want to separate out the repository for different projects so that i can bundle the repository along with my project's source code to be shared to the other person. I simply dont want to share my whole m2 repository (of size 2 gb) for a very small project sized 50 mb.
Regards,
Vibhav
You can specify repository location via command line option -Dmaven.repo.local=
I'd have just put a wrapper script to start maven in the project location and specified repository in it (probably pointing to location inside the project for your use case).
Thanks everyone for your comments.
I finally did the following:
Setup each project as a separate workspace in eclipse
Created a separate apache maven folder for each project (actually duplicating the maven home even though i am using same version of maven)
From eclipse workspace, I pointed out the appropriate maven home
configured the repository path (localRepository) in MAVEN_HOME/conf/settings.xml file from default ~./m2/repository to something like MAVEN_HOME/repo
This way, I could get separate maven repositories for each project (or I should say workspace).
Thanks,
Vibhav Agrawal
See the following answer:
Prevent Jenkins from Installing Artifact to Local Maven Repository
In a nutshell use a settings file for each build. Enables you to control both the local repository used for that project, but also other settings like repositories and build profiles.
My solution using Eclipse and Maven is to create new workspace, maven repository and settings.xml replacing the default .m2 repository path.
your new settings.xml
Then, try in Eclipse: Preferences>User Settings and browse your settings.xml
replace the User Settings file
I have a Maven project called Utils that i'm working on. I also have another project, called A, that uses classes of Utils. So, I've added a dependency to Utils in the POM of A. I precise that the two projects are not installed in the local repository (or another private repository). When I try to package the project A, I get an error because Maven tries to get the Utils project from the local repository and central repository, but it's not there. I don't want to install the project because it's not final, i don't want to give it a version because there is no release.
Thanks
It's safe to install the project into local repository. Just use mvn install in the Utils' project folder. Anytime you do install it will be replaced by newest in your local repo.
But don't deploy it, it means others could use it. In comparison, your local repo is used only by you.
It seems that the Maven plugin on Eclipse provides this possibility. And there is no need to install the artifacts corresponding to the active projects in the local repository. It seems that the plugin considers the workspace as a second local repository (you can see this using the Maven repositories view). First, the Workspace resolution feature must be enabled (Right click on the project then under Maven). When I want to run the project, I use Run configurations wizard, and Resolve workspace must be checked.
Is it a good solution? I don't know if it just seems to work or if it really works.
Thanks
I'm using Eclipse Helios and EGit 0.11.3.
I have a project where different branches use different versions of some of the libraries on my Java build path. For example, branch_old uses foo_lib_v1.0.jar while branch_new uses foo_lib_v2.0.jar.
If I'm working on branch_new and I need to checkout branch_old to test something, it's a bit of a hassle: I must manually reconfigure the build path in Eclipse before the project can build successfully.
Is there a way to store Eclipse's Java build path configuration for my project in git, so that when I check out a branch the build path is automatically modified? If not, is there another way to achieve the same result?
Thanks.
I see several choices here:
store project files (.classpath and .project) in Git as part of your branch. This way you would have to store all your dependencies in Git too, which is a hassle if you have a lot of them.
use Maven (m2eclipse plugin) and store project definition (pom.xml) file as part of your version control. Maven will greatly simplify your project dependency configuration
More information on m2eclipse plugin can be found at http://www.sonatype.com/books/m2eclipse-book/reference/
Should work: Put the .buildpath under version control. So its checkouted every time you switch the branches.
AFAIK Eclipse stores his build classpath in a file like .classpath(?) You can just add the file to git and have an own config for each branch.
Define several user libraries in your workspace, such as FooLib1, FooLib2, FooLib2. Then in the project's build path at a given branch reference the appropriate version of the library. Make sure you include project metadata files such as .classpath in your git repository and you should be set.