{{Virgo}} You can join the Virgo community by tweeting about #virgort, using the [http://www.eclipse.org/forums/index.php?t=thread&frm_id=159 Virgo forum], subscribing to the [https://dev.eclipse.org/mailman/listinfo/virgo-dev virgo-dev] mailing list, or using [https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced;order=Importance;classification=RT;product=Virgo bugzilla].

+

You can join the Virgo community by tweeting about <code lang="text">#virgort</code>, using the [http://www.eclipse.org/forums/index.php?t=thread&frm_id=159 Virgo forum], subscribing to the [https://dev.eclipse.org/mailman/listinfo/virgo-dev virgo-dev] mailing list, or using [https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced;order=Importance;classification=RT;product=Virgo bugzilla].

= Meetings =

= Meetings =

−

There is a weekly, one hour call at 14:00 UTC on Tuesdays to discuss Virgo. See [[Virgo/Discussion/Meetings|meetings]] for details.

+

There is a weekly, one hour call at 14:30 UK time on Mondays to discuss Virgo. See [[Virgo/Community/Meetings|meetings]] for details.

−

== Minutes ==

+

Very occasional face to face meetings will be held. See [[Virgo/Community/F2F|F2F]] for details.

−

+

−

*[[Virgo/Community/Minutes-2010-07-27|Minutes of 27 July 2010]] - this meeting did not in fact take place; apologies for the omission.

+

−

*[[Virgo/Community/Minutes-2010-07-20|Minutes of 20 July 2010]]

+

−

*[[Virgo/Community/Minutes-2010-07-13|Minutes of 13 July 2010]]

+

−

*[[Virgo/Community/Minutes-2010-07-06|Minutes of 6 July 2010]]

+

−

*[[Virgo/Community/Minutes-2010-06-29|Minutes of 29 June 2010]]

+

−

*[[Virgo/Community/Minutes-2010-06-22|Minutes of 22 June 2010]]

+

−

*[[Virgo/Community/Minutes-2010-06-15|Minutes of 15 June 2010]]

+

−

*[[Virgo/Community/Minutes-2010-06-08|Minutes of 8 June 2010]]

+

−

*[[Virgo/Community/Minutes-2010-06-01|Minutes of 1 June 2010]]

+

−

*[[Virgo/Community/Minutes-2010-05-25|Minutes of 25 May 2010]]

+

−

*[[Virgo/Community/Minutes-2010-05-18|Minutes of 18 May 2010]]

+

−

*[[Virgo/Community/Minutes-2010-05-11|Minutes of 11 May 2010]]

+

−

*[[Virgo/Community/Minutes-2010-05-04|Minutes of 4 May 2010]]

+

= Contributing =

= Contributing =

−

Suppose you see a need to change Virgo somehow. You can start by raising this on virgo-dev or as a bug, but suppose the committers don't dive in and make the change for you. Don't take this personally - Virgo is an active project and there's always more to do than the committers have time for. That's where contributors come in. You may not feel very confident about changing the Virgo codebase, but the only way to learn is to get your hands dirty. The committers are interested in building up the Virgo community and they should help you navigate the codebase and can provide useful feedback on changes you are proposing. So file a bug, attach your code, and take it from there. But before you do, please read on to understand what makes a good contribution.

+

Suppose you see a need to change Virgo somehow. You can start by raising this on ''Virgo-Dev'' or as a bug, but suppose the committers don't dive in and make the change for you. Don't take this personally - Virgo is an active project and there's always more to do than the committers have time for.

−

Start by reading the [http://www.eclipse.org/legal/termsofuse.php Eclipse.org Terms of Use] before making any contribution. Check out the flow chart in the [http://www.eclipse.org/legal/EclipseLegalProcessPoster.pdf Eclipse Legal Process poster]. In particular, please make sure that you wrote 100% of the contribution and did not copy content from elsewhere or rely on the intellectual property of others as that makes the contribution process so much simpler.

+

That's where ''contributors'' come in. You may not feel very confident about changing the Virgo codebase, but the best way to learn is to do. The committers are interested in building up the Virgo community and they should help you navigate the codebase and can provide useful feedback on changes you are proposing. So file a bug, attach your code, and take it from there. But before you do, please read on to understand what makes a good contribution.

−

Then attach your code as a patch (created using git diff) to a bugzilla bug so that a committer can perform the necessary due diligence checks. In the bug you must confirm that you wrote 100% of the code you contributed (in particular that you didn't copy any of the code from elsewhere), that you have the right to contribute the code to Eclipse (e.g. your employer agrees or you wrote the code in your own time and your contract does not imply that the code is therefore your employer's), and that any new files contain the appropriate License header with yourself or your company, as appropriate, as the copyright owner and yourself as the initial contributor.

+

'''a good contributor'''

−

You should probably discuss large contributions (more than 250 lines of code and/or configuration) on the virgo-dev mailing list first so everyone knows what's going on.

+

* starts by reading the [http://www.eclipse.org/legal/termsofuse.php Eclipse.org Terms of Use] before making any contribution

+

* checks out the flow chart in the [http://www.eclipse.org/legal/EclipseLegalProcessPoster.pdf Eclipse Legal Process poster]

+

In particular…

+

* ensures that they wrote 100% of the contribution and did not copy content from elsewhere or rely on the intellectual property of others.

−

Contributions should include unit tests whenever possible and integration tests where appropriate. This ensures that the contributed code is well structured and can be tested as well as avoiding the technical debt of code waiting to be tested.

+

That makes the contribution process so much simpler.

−

See {{VirgoLink|Committers|Committers|{{{tab}}}|committers}} for information about coding conventions and testing which will make your contribution more easily consumed by Virgo.

+

Then…

+

* attaches the code as a patch (easily created using git diff) to a Bugzilla bug (under RT/Virgo/core) so that a committer can perform the necessary due diligence checks.

−

= Take Virgo for a spin =

+

'''essential steps'''

−

If you want to take the Virgo web server for a spin, first [http://www.eclipse.org/virgo/download/ download it]&nbsp;and unpack the downloaded archive to a directory, which we will refer to as $SERVER_HOME, ensuring there are no spaces in the path of the directory. On Windows unzip to a directory, which we will refer to as %SERVER_HOME%, again ensuring there are no spaces in the path of the directory. We recommend 7zip for unpacking on Windows as the built-in zip extraction utility sometimes fail to unpack reliably.

+

In the bug the contributor (that's you) must confirm that they wrote 100% of the code contributed (in particular that none of it is copied from elsewhere), that they have the right to contribute the code to Eclipse (e.g. the employer agrees or the code is produced in personal time and contracts do not assign ownership or copyright to the employer), and that any new files contain the appropriate License header with the contributor (or the employer, as appropriate) as the copyright owner and the contributor as the "initial contributor". (See existing files in the Virgo source code repositories for examples of the copyright and license headers.)

−

Then start the Virgo web server. On Unix, issue the following commands from a shell:

+

'''optional steps'''

−

<pre>&gt;cd $SERVER_HOME

+

−

&gt;bin/startup.sh

+

−

</pre>

+

−

On Windows, issue the following commands in a command prompt:

+

−

<pre>&gt;cd %SERVER_HOME%

+

−

&gt;bin\startup.bat

+

−

</pre>

+

−

Virgo should issue event log messages like this:

+

See {{VirgoLink|Committers|Committers|{{{tab}}}|committers}} for information about coding conventions and testing which will make your contribution more easily consumed by Virgo.

You can then [http://localhost:8080/admin log in] to the Virgo admin console (user "admin", password "springsource"). You should see the welcome panel of the admin console:<br>[[Image:VirgoAdminConsole.png|center|admin console welcome panel]]

+

−

You can then examine the features of the admin console. For example, you can explore the artifacts currently installed by clicking on the Artifacts pane and expanding some of the sections marked with '+' signs:

+

Contributions should include unit tests whenever possible and integration tests where appropriate. This ensures that the contributed code is well structured and can be tested, as well as avoiding the technical debt of code waiting to be tested. The committers that handle the contribution will assess these criteria.

You should probably discuss large contributions (more than 250 lines of code and/or configuration) on the virgo-dev mailing list first so everyone knows what's going on. Small patches and additions (e.g. extra unit tests) can be made with little or no discussion. Remember that patches or enhancements can often include 'too much'. It is tempting to include unrelated changes with another idea -- simply because they are 'close by' in the code. No-one is particularly at fault here, but if patches are ruthlessly reduced to the smallest possible units they are more likely to get in. Small is beautiful, and minimal is marvellous.

−

If you want to try deploying a bundle, drop it into the pickup directory:

+

So, silly as it may seem, if you spot a single line correction (or 'improvement') while writing your ''magnum opus'', please resist the urge to 'just put it in'. If a single line bugzilla patch is raised, it can get in much more easily than a collection of changes, and is quicker and simpler for all concerned. If the change is unrelated, or just 'independent' in the sense that it ''could'' be made separately without harm, then please ''do'' separate it. That way it won't be 'caught up' in a long discussion (and possible rejection) that has nothing to do with it.

For example, if you download the trivial test application [http://git.eclipse.org/c/virgo/org.eclipse.virgo.web.git/plain/org.eclipse.virgo.web.test/src/test/apps-static/helloweb.war helloweb.war] and drop it into the pickup directory, the following event log messages are displayed:

The main package changes are shown in the following table although very few of these are likely to impact applications. Users who have modified or extended dm Server are far more likely to be affected.

+

−

+

−

<br>

+

−

+

−

{| width="200" border="1" cellpadding="1" cellspacing="1"

+

−

|+ Package changes

+

−

|-

+

−

! '''dm Server 2.0.x'''

+

−

! '''Virgo 2.1.0.x'''

+

−

|-

+

−

| com.springsource.osgi.teststubs.*

+

−

| org.eclipse.virgo.teststubs.osgi.*

+

−

|-

+

−

| com.springsource.osgi.extensions.*

+

−

| org.eclipse.virgo.osgi.extensions.*

+

−

|-

+

−

| com.springsource.osgi.launcher.*

+

−

| org.eclipse.virgo.osgi.launcher.*

+

−

|-

+

−

| com.springsource.util.*

+

−

| org.eclipse.virgo.util.*

+

−

|-

+

−

| com.springsource.osgi.test.*

+

−

| org.eclipse.virgo.test.*

+

−

|-

+

−

| com.springsource.osgi.medic.*

+

−

| org.eclipse.virgo.medic.*

+

−

|-

+

−

| com.springsource.repository.*

+

−

| org.eclipse.virgo.repository.*

+

−

|-

+

−

| com.springsource.kernel.*

+

−

| org.eclipse.virgo.kernel.*

+

−

|-

+

−

| com.springsource.osgi.webcontainer.*

+

−

| org.eclipse.gemini.web.*

+

−

|-

+

−

| com.springsource.server.*

+

−

| org.eclipse.virgo.*

+

−

|}

+

−

+

−

=== Shell ===

+

−

+

−

The kernel shell did not make it through the stringent Eclipse IP process and so Virgo extends the Equinox console instead.

+

−

+

−

The inline shell is no longer supported and the "-shell" switch on the startup script produces a warning.

+

−

+

−

The Equinox console is configured in the user region properties file via the osgi.console property with a default value of 2401.

+

−

+

−

The kernel properties shell.enabled and shell.port are no longer used and are ignored if specified. Remote access to the Equinox console is via telnet (whereas the kernel shell supported ssh).

+

−

+

−

=== Service Wrapper ===

+

−

+

−

The service wrapper did not make it through the stringent Eclipse IP process and so is no longer supported. Anyone needing this function will need to create their own service wrapper or take the one from dm Server 2.0.x and doctor it.

Even though the slices project was a prototype, a number of dm Server users found it very useful and asked for it to be made available on Virgo. It is currently being renamed to "snaps" and contributed to Virgo.

+

−

+

−

There will be a one-time hit for users to migrate from slices to snaps, largely because of the renaming.

+

−

+

−

=== Samples ===

+

−

+

−

The Petclinic and Spring Travel based samples are not provided with snaps as they derive from code whose authorship is not clear.

+

−

+

−

=== Package Names ===

+

−

+

−

The Java package names of the code have been renamed from com.springsource.osgi.slices.* or org.eclipse.virgo.snaps.*.

+

−

+

−

=== Class names ===

+

−

+

−

'Slice' is replaced by 'Snap' in class names.

+

−

+

−

{| width="50%" border="1" cellpadding="1" cellspacing="1"

+

−

|+ Notable class name changes

+

−

|-

+

−

! '''dm Server slices'''

+

−

! '''Virgo snaps'''

+

−

|-

+

−

| com.springsource.osgi.slices.core.SliceHostFilter

+

−

| org.eclipse.virgo.snaps.core.SnapHostFilter

+

−

|-

+

−

| com.springsource.osgi.slices.Slices

+

−

| org.eclipse.virgo.snaps.Snaps

+

−

|-

+

−

| com.springsource.osgi.slices.SlicesTag

+

−

| org.eclipse.virgo.snaps.SnapsTag

+

−

|}

+

−

+

−

=== Manifest headers ===

+

−

+

−

'Slice' is replaced by 'Snap' in manifest headers.

+

−

+

−

{| width="30%" border="1" cellpadding="1" cellspacing="1"

+

−

|+ Manifest header changes

+

−

|-

+

−

! '''dm Server slices'''

+

−

! '''Virgo snaps'''

+

−

|-

+

−

| Slice-Host

+

−

| Snap-Host

+

−

|-

+

−

| Slice-ContextPath

+

−

| Snap-ContextPath

+

−

|}

+

−

+

−

=== Bundle symbolic names ===

+

−

+

−

{| width="30%" border="1" cellpadding="1" cellspacing="1"

+

−

|+ Bundle symbolic name changes

+

−

|-

+

−

! '''dm Server slices'''

+

−

! '''Virgo snaps'''

+

−

|-

+

−

| com.springsource.osgi.slices.api

+

−

| org.eclipse.virgo.snaps.api

+

−

|-

+

−

| com.springsource.osgi.slices.core

+

−

| org.eclipse.virgo.snaps.core

+

−

|}

+

−

+

−

=== Plan names ===

+

−

{| width="30%" border="1" cellpadding="1" cellspacing="1"

+

If you want to take the Virgo server for a spin, go [[Virgo/Community/Spin|here]].

*&nbsp;A Virgo overview presentation, dating from June 2010, licensed under the Eclipse Public License for anyone who wants to present it or use it to create their own presentation on Virgo. It is provided in [http://wiki.eclipse.org/images/9/91/VirgoOverview.odp.zip open office] and [http://wiki.eclipse.org/images/a/af/VirgoOverview.pdf PDF] formats.

*&nbsp;A Virgo overview presentation, dating from June 2010, licensed under the Eclipse Public License for anyone who wants to present it or use it to create their own presentation on Virgo. It is provided in [http://wiki.eclipse.org/images/9/91/VirgoOverview.odp.zip open office] and [http://wiki.eclipse.org/images/a/af/VirgoOverview.pdf PDF] formats.

Contents

Meetings

There is a weekly, one hour call at 14:30 UK time on Mondays to discuss Virgo. See meetings for details.

Very occasional face to face meetings will be held. See F2F for details.

Contributing

Suppose you see a need to change Virgo somehow. You can start by raising this on Virgo-Dev or as a bug, but suppose the committers don't dive in and make the change for you. Don't take this personally - Virgo is an active project and there's always more to do than the committers have time for.

That's where contributors come in. You may not feel very confident about changing the Virgo codebase, but the best way to learn is to do. The committers are interested in building up the Virgo community and they should help you navigate the codebase and can provide useful feedback on changes you are proposing. So file a bug, attach your code, and take it from there. But before you do, please read on to understand what makes a good contribution.

ensures that they wrote 100% of the contribution and did not copy content from elsewhere or rely on the intellectual property of others.

That makes the contribution process so much simpler.

Then…

attaches the code as a patch (easily created using git diff) to a Bugzilla bug (under RT/Virgo/core) so that a committer can perform the necessary due diligence checks.

essential steps

In the bug the contributor (that's you) must confirm that they wrote 100% of the code contributed (in particular that none of it is copied from elsewhere), that they have the right to contribute the code to Eclipse (e.g. the employer agrees or the code is produced in personal time and contracts do not assign ownership or copyright to the employer), and that any new files contain the appropriate License header with the contributor (or the employer, as appropriate) as the copyright owner and the contributor as the "initial contributor". (See existing files in the Virgo source code repositories for examples of the copyright and license headers.)

optional steps

See Committers for information about coding conventions and testing which will make your contribution more easily consumed by Virgo.

Contributions should include unit tests whenever possible and integration tests where appropriate. This ensures that the contributed code is well structured and can be tested, as well as avoiding the technical debt of code waiting to be tested. The committers that handle the contribution will assess these criteria.

You should probably discuss large contributions (more than 250 lines of code and/or configuration) on the virgo-dev mailing list first so everyone knows what's going on. Small patches and additions (e.g. extra unit tests) can be made with little or no discussion. Remember that patches or enhancements can often include 'too much'. It is tempting to include unrelated changes with another idea -- simply because they are 'close by' in the code. No-one is particularly at fault here, but if patches are ruthlessly reduced to the smallest possible units they are more likely to get in. Small is beautiful, and minimal is marvellous.

So, silly as it may seem, if you spot a single line correction (or 'improvement') while writing your magnum opus, please resist the urge to 'just put it in'. If a single line bugzilla patch is raised, it can get in much more easily than a collection of changes, and is quicker and simpler for all concerned. If the change is unrelated, or just 'independent' in the sense that it could be made separately without harm, then please do separate it. That way it won't be 'caught up' in a long discussion (and possible rejection) that has nothing to do with it.

Currently Under Discussion

There are topics for discussion that have got beyond a forum thread. Please feel free to contribute your design thoughts.

Presentations

A Virgo overview presentation, dating from June 2010, licensed under the Eclipse Public License for anyone who wants to present it or use it to create their own presentation on Virgo. It is provided in open office and PDF formats.