Re: [m2] Maven vs source control
I have a question about how to combine the structure of source/resource files
as required by Maven and as suggested by version control. Of course you're
familiar with the Maven structure, and the structure of the version control
is often PROJECT/{trunk,branches,tags}
How would an example of the hierarchy of source folders and files therefore
look in the version control repository for source? Would the first level in
the hierarchy (topmost level) be PROJECT, or would it be
{trunk,branches,tags} further subdivided by project?
(I ask this question assuming multiple projects, branches, and tags.)
Is this layout flexible, or do Maven's usual rules for directory structure
dictate a certain layout when combined with version control layouts?
lightbulb432 wrote:
What's the difference between Maven and version control repositories when
you're using both? Maven has its repository, but so does my version
control.
As I'm fairly new to this, could somebody explain the division of
responsibility between Maven and version control specifically? e.g. Once
you've organized your project in the Maven hierarchy, what do you do then?
What to do about JARs which are in the Maven repository?
Is it possible to version everything in Maven using source control,
including the library repository?
--
View this message in context:
http://www.nabble.com/Maven-vs-source-control-tf3221731s177.html#a8968901
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] Maven vs source control
On 2/14/07, lightbulb432 [EMAIL PROTECTED] wrote:
I have a question about how to combine the structure of source/resource
files
as required by Maven and as suggested by version control. Of course you're
familiar with the Maven structure, and the structure of the version
control
is often PROJECT/{trunk,branches,tags}
How would an example of the hierarchy of source folders and files
therefore
look in the version control repository for source? Would the first level
in
the hierarchy (topmost level) be PROJECT, or would it be
{trunk,branches,tags} further subdivided by project?
I suggest project
You check out $SVNROOT/project1/trunk as project1and your IDE should
handle it normally (it then knows how to tag, etc)
You use in there a standard layout for a maven project.
--
Régis
http://regis.decamps.info/
Re: [m2] Maven vs source control
Thanks for your answer. Could you expand on why there's little point in versioning things in Maven. I guess maybe I can understand why for the library repository (is it because it in itself is almost versioned?), but what about everything else in Maven? e.g. your project tree that you're developing with the source code, configuration files, etc... I'm not sure what you meant by there might be a point to versioning everything in Maven using source control only when you version control server can behave like a webserver Graham Leggett wrote: On Tue, February 13, 2007 6:40 pm, lightbulb432 wrote: What's the difference between Maven and version control repositories when you're using both? Maven has its repository, but so does my version control. repository is the word used in both cases to describe the data store of record for each system, but a maven repository doesn't work anything like a version control repository, and vice versa. They aren't the same thing. In a version control system, a repository is the place where all the versions of the source being stored is kept. In maven, the repository is a big directory tree where jar files[1] are stored, in such a way that the jar files can be referenced quickly and easily by maven. Is it possible to version everything in Maven using source control, including the library repository? No[2], there is little point in doing this. [1] Or other files, maven repos can contain artifacts other than jar, but jar is most common. [2] Ok, theoretically yes, but only when you version control server can behave like a webserver. Regards, Graham -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Maven-vs-source-control-tf3221731s177.html#a8948205 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] Maven vs source control
They are completely different albeit related subjects... You have a code repository to manage versions of source files. You could perhaps attempt to use Maven without a code repository but virtually all modern development efforts will utilize some kind of code repo. You have a Maven repository to manage versions of compiled Java modules. Maven pulls code from your code repository to build the modules, which are then deployed to your Maven repository. Everything in the Maven repo is intrinsically versioned through the project object model. You can safely ignore his comment about versioning everything in Maven using source control until you fully understand these points. Then you can revisit this point, but understand that very few people in the world who are using Maven will bother to put their Maven repo under source control. Wayne On 2/13/07, lightbulb432 [EMAIL PROTECTED] wrote: Thanks for your answer. Could you expand on why there's little point in versioning things in Maven. I guess maybe I can understand why for the library repository (is it because it in itself is almost versioned?), but what about everything else in Maven? e.g. your project tree that you're developing with the source code, configuration files, etc... I'm not sure what you meant by there might be a point to versioning everything in Maven using source control only when you version control server can behave like a webserver Graham Leggett wrote: On Tue, February 13, 2007 6:40 pm, lightbulb432 wrote: What's the difference between Maven and version control repositories when you're using both? Maven has its repository, but so does my version control. repository is the word used in both cases to describe the data store of record for each system, but a maven repository doesn't work anything like a version control repository, and vice versa. They aren't the same thing. In a version control system, a repository is the place where all the versions of the source being stored is kept. In maven, the repository is a big directory tree where jar files[1] are stored, in such a way that the jar files can be referenced quickly and easily by maven. Is it possible to version everything in Maven using source control, including the library repository? No[2], there is little point in doing this. [1] Or other files, maven repos can contain artifacts other than jar, but jar is most common. [2] Ok, theoretically yes, but only when you version control server can behave like a webserver. Regards, Graham -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Maven-vs-source-control-tf3221731s177.html#a8948205 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] Maven vs source control
Oh, now I see the difference, being between the mgmt of source files and of compiled modules. So if you are making minor revisions of your source repository all the time, does that mean your module repository is going to get enormous (because everytime you make a tiny change in your source, that classifies as a new module altogether, and the entire project gets put in its packaged form into the Maven repo?) What's the best practice regarding what people generally do? Do they only put their source code into the Maven repo as a module when its a release, rather than just another change as part of the development process? It's slowly coming together now, thanks... Wayne Fay wrote: They are completely different albeit related subjects... You have a code repository to manage versions of source files. You could perhaps attempt to use Maven without a code repository but virtually all modern development efforts will utilize some kind of code repo. You have a Maven repository to manage versions of compiled Java modules. Maven pulls code from your code repository to build the modules, which are then deployed to your Maven repository. Everything in the Maven repo is intrinsically versioned through the project object model. You can safely ignore his comment about versioning everything in Maven using source control until you fully understand these points. Then you can revisit this point, but understand that very few people in the world who are using Maven will bother to put their Maven repo under source control. Wayne On 2/13/07, lightbulb432 [EMAIL PROTECTED] wrote: Thanks for your answer. Could you expand on why there's little point in versioning things in Maven. I guess maybe I can understand why for the library repository (is it because it in itself is almost versioned?), but what about everything else in Maven? e.g. your project tree that you're developing with the source code, configuration files, etc... I'm not sure what you meant by there might be a point to versioning everything in Maven using source control only when you version control server can behave like a webserver Graham Leggett wrote: On Tue, February 13, 2007 6:40 pm, lightbulb432 wrote: What's the difference between Maven and version control repositories when you're using both? Maven has its repository, but so does my version control. repository is the word used in both cases to describe the data store of record for each system, but a maven repository doesn't work anything like a version control repository, and vice versa. They aren't the same thing. In a version control system, a repository is the place where all the versions of the source being stored is kept. In maven, the repository is a big directory tree where jar files[1] are stored, in such a way that the jar files can be referenced quickly and easily by maven. Is it possible to version everything in Maven using source control, including the library repository? No[2], there is little point in doing this. [1] Or other files, maven repos can contain artifacts other than jar, but jar is most common. [2] Ok, theoretically yes, but only when you version control server can behave like a webserver. Regards, Graham -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Maven-vs-source-control-tf3221731s177.html#a8948205 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Maven-vs-source-control-tf3221731s177.html#a8948818 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] Maven vs source control
Generally people use the SNAPSHOT feature of Maven during development (with typically only 1 version per artifact, which is frequently updated but always uses the version SNAPSHOT), and then periodically deploy versions of modules to the Maven repo when the development team has decided to cut a new release. You can run the entire Maven compile, test, package process without actually deploying code to your repo, so we usually only deploy code when we are pushing our a new version of a module/project. Wayne On 2/13/07, lightbulb432 [EMAIL PROTECTED] wrote: Oh, now I see the difference, being between the mgmt of source files and of compiled modules. So if you are making minor revisions of your source repository all the time, does that mean your module repository is going to get enormous (because everytime you make a tiny change in your source, that classifies as a new module altogether, and the entire project gets put in its packaged form into the Maven repo?) What's the best practice regarding what people generally do? Do they only put their source code into the Maven repo as a module when its a release, rather than just another change as part of the development process? It's slowly coming together now, thanks... Wayne Fay wrote: They are completely different albeit related subjects... You have a code repository to manage versions of source files. You could perhaps attempt to use Maven without a code repository but virtually all modern development efforts will utilize some kind of code repo. You have a Maven repository to manage versions of compiled Java modules. Maven pulls code from your code repository to build the modules, which are then deployed to your Maven repository. Everything in the Maven repo is intrinsically versioned through the project object model. You can safely ignore his comment about versioning everything in Maven using source control until you fully understand these points. Then you can revisit this point, but understand that very few people in the world who are using Maven will bother to put their Maven repo under source control. Wayne On 2/13/07, lightbulb432 [EMAIL PROTECTED] wrote: Thanks for your answer. Could you expand on why there's little point in versioning things in Maven. I guess maybe I can understand why for the library repository (is it because it in itself is almost versioned?), but what about everything else in Maven? e.g. your project tree that you're developing with the source code, configuration files, etc... I'm not sure what you meant by there might be a point to versioning everything in Maven using source control only when you version control server can behave like a webserver Graham Leggett wrote: On Tue, February 13, 2007 6:40 pm, lightbulb432 wrote: What's the difference between Maven and version control repositories when you're using both? Maven has its repository, but so does my version control. repository is the word used in both cases to describe the data store of record for each system, but a maven repository doesn't work anything like a version control repository, and vice versa. They aren't the same thing. In a version control system, a repository is the place where all the versions of the source being stored is kept. In maven, the repository is a big directory tree where jar files[1] are stored, in such a way that the jar files can be referenced quickly and easily by maven. Is it possible to version everything in Maven using source control, including the library repository? No[2], there is little point in doing this. [1] Or other files, maven repos can contain artifacts other than jar, but jar is most common. [2] Ok, theoretically yes, but only when you version control server can behave like a webserver. Regards, Graham -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Maven-vs-source-control-tf3221731s177.html#a8948205 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Maven-vs-source-control-tf3221731s177.html#a8948818 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe,
Re: [m2] Maven vs source control
lightbulb432 wrote: Could you expand on why there's little point in versioning things in Maven. I guess maybe I can understand why for the library repository (is it because it in itself is almost versioned?), but what about everything else in Maven? e.g. your project tree that you're developing with the source code, configuration files, etc... One of the core concepts within maven is its version number scheme. Maven makes a strong distinction between released artifacts, and snapshot artifacts. Your project while you are working on it, your dev branch, is an example of a snapshot artifact - despite the fact that it probably has a version number already, every time you rebuild your code, you have replaced your previous snapshot build with your new one. Snapshot artifacts have the suffix -SNAPSHOT after the version number. Once you have released a particular tag of your project, you publish it as a released artifact, probably into a publically accessible (or publically accessible within your company) maven repository. Many many other projects have also deployed their released artifacts into public maven repositories like http://repo1.maven.org, and this code is automatically available to you as well. The key point is this: Once an artifact is published with a released version number, that artifact never changes again. Should the artifact get updated, a new release is made with a new version number, and the newer released artifact sits beside the older released artifact. This is why it's largely pointless to place jars in version control, as the jars as released and published don't change and mustn't change. Of course you could try and subvert the system and upload a replacement jar that replaces an existing released version - the trouble is, maven by design knows that released jar files don't change, and if maven has a local copy of the older jar, it will never try and download the new jar. This is why protecting write access to your maven repository in a corporate environment is generally a good idea, as you don't want a developer changing the goalposts on already released code. This same issue exists even if you do try store jars in version control, because you don't want a developer messing around there for the same reasons. I'm not sure what you meant by there might be a point to versioning everything in Maven using source control only when you version control server can behave like a webserver maven (to my knowledge) expects a maven repository to be either a directory local on the machine, or published on a webserver. In order to host a maven repository inside a version control server, the version control server must behave like a webserver, and the only version control server capable of this to my knowledge is subversion. Don't worry too much about this point - it was an aside. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: [m2] Maven vs source control
lightbulb432 wrote: So if you are making minor revisions of your source repository all the time, does that mean your module repository is going to get enormous (because everytime you make a tiny change in your source, that classifies as a new module altogether, and the entire project gets put in its packaged form into the Maven repo?) Yes, meaning that at some point you might want to remove very old artifacts and archive them away somewhere, when you are sure they will never be needed again. Practically speaking though, it is unlikely in most cases you would ever need to do this, as compared to typical disk partition sizes, and typical jar sizes, it takes an awful lot of versions before this becomes a problem. What's the best practice regarding what people generally do? Do they only put their source code into the Maven repo as a module when its a release, rather than just another change as part of the development process? All our source code goes into version control, and source releases are tagged in version control. We have a company-private maven repository in the form of a webserver that contains all our jar releases over time. This serves as a record of all artifacts that ever went into uat or production. This repository doesn't contain any snapshots, although it is possible to host snapshots in a repository if you want to (just watch the disk space). This means that we have at any time, both the source code, as well as the resultant binaries as released, for all modules we maintain. Source under version control, binaries in a maven repository. Maintaining all of this sounds frightening, however maven plugins exist that automate many of the tasks associated with making releases and deploying them places. This helps you avoid many of the pitfalls involved in managing releases properly, the chief pitfall being developers who bypass your rules for releases and do their own thing. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
