You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by Niklas Gustavsson <ni...@protocol7.com> on 2009/06/21 00:04:17 UTC
Move Vysper from sandbox
Hi
For Vysper, the export page has been updated
(https://issues.apache.org/jira/browse/VYSPER-47), Bernd has assembled
a list of all contributors
(https://issues.apache.org/jira/browse/VYSPER-45) and I think we've
done the due diligence even though the issue is not closed
(https://issues.apache.org/jira/browse/VYSPER-44). Therefore, I think
it's time to move Vysper out of the sandbox. If no one objects, I'll
start a vote in a few days.
/niklas
Re: Move Vysper from sandbox
Posted by Emmanuel Lecharny <el...@apache.org>.
Alex just expressed what I had in mind much better than I did !
Sometime, it helps to be a native english speaker :)
( I don't know how many time some frustration arose from the
incapacity we have to express with the correct wording what we really
think ...)
Thanks guys !
On Sun, Jun 21, 2009 at 5:39 PM, Niklas Gustavsson<ni...@protocol7.com> wrote:
> On Sun, Jun 21, 2009 at 12:01 PM, Emmanuel Lecharny<el...@apache.org> wrote:
>> I didn't said that Vysper should not exit the sandbox, sorry of it was
>> interpreted this way.
>
> Oh, that was just me reading to much into your reply. And I should
> probably have mentioned that I do not think Vysper is ready for a
> release (for the exact reason you point out) but getting out of the
> sandbox is probably just for the better in getting this fixed.
>
> As Alex points out, we've had our fair share of issues in this area
> before, so maybe we should put some additional focus on documentation
> (both Javadoc and getting the wiki up and running).
>
> /niklas
>
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: Move Vysper from sandbox
Posted by Niklas Gustavsson <ni...@protocol7.com>.
On Sun, Jun 21, 2009 at 12:01 PM, Emmanuel Lecharny<el...@apache.org> wrote:
> I didn't said that Vysper should not exit the sandbox, sorry of it was
> interpreted this way.
Oh, that was just me reading to much into your reply. And I should
probably have mentioned that I do not think Vysper is ready for a
release (for the exact reason you point out) but getting out of the
sandbox is probably just for the better in getting this fixed.
As Alex points out, we've had our fair share of issues in this area
before, so maybe we should put some additional focus on documentation
(both Javadoc and getting the wiki up and running).
/niklas
Re: Move Vysper from sandbox
Posted by Emmanuel Lecharny <el...@apache.org>.
Niklas Gustavsson wrote:
> On Sun, Jun 21, 2009 at 12:19 AM, Emmanuel Lecharny<el...@apache.org> wrote:
>
>> Well, sorry for being a bit a PITA, but I would like to see more javadoc in
>> the project. We already have been burnt (and still are !!!) with MINA
>> suffering from such a problem that I would like to avoid it again.
>>
>
> While I certainly agree that Vysper need more documentation in all
> forms (as does probably all of our projects), I don't think that's a
> reason to keep it in the sandbox. To me, sandbox is for code which has
> not gone through all the required formal vetting (something I think
> Vysper now has). As for attracting more people to the code and get
> more people to contribute (to code as well as docs), hiding it away in
> the sandbox won't help.
>
I didn't said that Vysper should not exit the sandbox, sorry of it was
interpreted this way.
I was just raising a warning.
It's obvious that moving to a more visible place will help to get more
people aggregating around the project.
So +1 to get Vysper move to trunk and +1 for more javadoc too...
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: Move Vysper from sandbox
Posted by Niklas Gustavsson <ni...@protocol7.com>.
On Sun, Jun 21, 2009 at 12:19 AM, Emmanuel Lecharny<el...@apache.org> wrote:
> Well, sorry for being a bit a PITA, but I would like to see more javadoc in
> the project. We already have been burnt (and still are !!!) with MINA
> suffering from such a problem that I would like to avoid it again.
While I certainly agree that Vysper need more documentation in all
forms (as does probably all of our projects), I don't think that's a
reason to keep it in the sandbox. To me, sandbox is for code which has
not gone through all the required formal vetting (something I think
Vysper now has). As for attracting more people to the code and get
more people to contribute (to code as well as docs), hiding it away in
the sandbox won't help.
/niklas
Re: Move Vysper from sandbox
Posted by Alex Karasulu <ak...@gmail.com>.
Hi gang,
I think we're all a bit sensitive after having dealt with a situation where
a code base was left almost totally undocumented by a developer here at
MINA.
I think Emmanuel makes good points and so do the Bernard and others. Let's
all work together to ameliorate our fears from the past while getting this
project the exposure it deserves to grow community. We should take this out
of the sandbox but let's throw in a few hours here and there to make sure
what happened in the past never happens again.
Also let's just be relaxed about it. Let me know if I can help out in any
way.
Thanks,
Alex
On Sun, Jun 21, 2009 at 10:25 AM, Emmanuel Lecharny <el...@apache.org>wrote:
> Bernd Fondermann wrote:
>
>> To turn this into an actually task, could you point out areas/classes
>> that especially lack javadoc?
>>
>>
> I have conducted a quick review of around one third of the java files (test
> excluded). I have tagged all the files I reviewed with :
> * J : files without javadoc
> * j : files with partial Javadoc
> * H : files without a description in the header
> * A : missing @author tag
> * OK : files with all the needed javadoc, header and @author tag
>
> Some of them combine mor ethan one of those missing elements.
>
> I have found only 8 OK files oit of 96 files I checked. Here is the list
> (files without one of those tags haven't be checked yet)
>
> Note that I may have been inaccurate to some extent.
>
>
>
> J org/apache/vysper/mina/MinaBackedSessionContext.java
> JH org/apache/vysper/mina/XmppIoHandlerAdapter.java
> J org/apache/vysper/mina/TCPEndpoint.java
> J org/apache/vysper/mina/codec/XMLStreamTokenizer.java
> J org/apache/vysper/mina/codec/StanzaWriteInfo.java
> J org/apache/vysper/mina/codec/XMPPProtocolCodecFactory.java
> J org/apache/vysper/mina/codec/StanzaWriterProtocolEncoder.java
> org/apache/vysper/xmpp/uuid/UUIDGenerator.java
> org/apache/vysper/xmpp/uuid/JVMBuiltinUUIDGenerator.java
> org/apache/vysper/xmpp/xmldecoder/UnsupportedXMLException.java
> org/apache/vysper/xmpp/xmldecoder/DecodingException.java
> org/apache/vysper/xmpp/xmldecoder/XMLParticle.java
> org/apache/vysper/xmpp/xmldecoder/XMLRawToFragmentConverter.java
> org/apache/vysper/xmpp/xmldecoder/ParticleDecoder.java
> JA org/apache/vysper/xmpp/datetime/DateTimeProfile.java
> org/apache/vysper/xmpp/state/resourcebinding/ResourceRegistry.java
> org/apache/vysper/xmpp/state/resourcebinding/ResourceState.java
> org/apache/vysper/xmpp/state/resourcebinding/BindException.java
> org/apache/vysper/xmpp/state/presence/LatestPresenceCache.java
> org/apache/vysper/xmpp/state/presence/SimplePresenceCache.java
> org/apache/vysper/xmpp/state/presence/PresenceCachingException.java
> J org/apache/vysper/xmpp/authorization/External.java
> OK org/apache/vysper/xmpp/authorization/UserAuthorization.java
> J org/apache/vysper/xmpp/authorization/SimpleUserAuthorization.java
> JH org/apache/vysper/xmpp/authorization/AccountCreationException.java
> H org/apache/vysper/xmpp/authorization/AccountManagement.java
> J org/apache/vysper/xmpp/authorization/Anonymous.java
> J org/apache/vysper/xmpp/authorization/AuthorizationResponses.java
> J org/apache/vysper/xmpp/authorization/Plain.java
> OK org/apache/vysper/xmpp/authorization/SASLMechanism.java
> JH org/apache/vysper/xmpp/addressing/EntityFormatException.java
> A1 org/apache/vysper/xmpp/addressing/stringprep/StringPrepConstants.java
> jA1 org/apache/vysper/xmpp/addressing/stringprep/StringPrep.java
> JA1H
> org/apache/vysper/xmpp/addressing/stringprep/StringPrepViolationException.java
> ja1 org/apache/vysper/xmpp/addressing/stringprep/ResourcePrep.java
> ja1 org/apache/vysper/xmpp/addressing/stringprep/NodePrep.java
> J org/apache/vysper/xmpp/addressing/Entity.java
> J org/apache/vysper/xmpp/addressing/EntityImpl.java
> JH org/apache/vysper/xmpp/addressing/EntityConformance.java
> J
> org/apache/vysper/xmpp/modules/core/im/handler/PresenceAvailabilityHandler.java
> J org/apache/vysper/xmpp/modules/core/im/handler/PresenceHandler.java
> J
> org/apache/vysper/xmpp/modules/core/im/handler/PresenceSubscriptionHandler.java
> JH
> org/apache/vysper/xmpp/modules/core/im/handler/AbstractPresenceSpecializedHandler.java
> J
> org/apache/vysper/xmpp/modules/core/base/BaseStreamStanzaDictionary.java
> J
> org/apache/vysper/xmpp/modules/core/base/handler/DefaultIQHandler.java
> h
> org/apache/vysper/xmpp/modules/core/base/handler/async/RunnableFuture.java
> J
> org/apache/vysper/xmpp/modules/core/base/handler/async/ResponseFuture.java
> j
> org/apache/vysper/xmpp/modules/core/base/handler/async/AbstractAsyncIQGetHandler.java
> J org/apache/vysper/xmpp/modules/core/base/handler/IQHandler.java
> JH
> org/apache/vysper/xmpp/modules/core/base/handler/StreamStartHandler.java
> J
> org/apache/vysper/xmpp/modules/core/base/handler/XMPPCoreStanzaHandler.java
> J org/apache/vysper/xmpp/modules/core/base/handler/MessageHandler.java
> JH
> org/apache/vysper/xmpp/modules/core/base/handler/XMLPrologHandler.java
> J org/apache/vysper/xmpp/modules/core/bind/handler/BindIQHandler.java
> J org/apache/vysper/xmpp/modules/core/bind/BindResourceDictionary.java
> J
> org/apache/vysper/xmpp/modules/core/sasl/AuthorizationRetriesCounter.java
> J org/apache/vysper/xmpp/modules/core/sasl/SASLFailureType.java
> J org/apache/vysper/xmpp/modules/core/sasl/SASLStanzaDictionary.java
> JH org/apache/vysper/xmpp/modules/core/sasl/handler/AuthHandler.java
> JH
> org/apache/vysper/xmpp/modules/core/sasl/handler/AbstractSASLHandler.java
> JH org/apache/vysper/xmpp/modules/core/sasl/handler/AbortHandler.java
> J
> org/apache/vysper/xmpp/modules/core/session/SessionStanzaDictionary.java
> J
> org/apache/vysper/xmpp/modules/core/session/handler/SessionIQHandler.java
> J
> org/apache/vysper/xmpp/modules/core/compatibility/jabber_iq_auth/JabberIQAuthDictionary.java
> J
> org/apache/vysper/xmpp/modules/core/compatibility/jabber_iq_auth/handler/AuthCompatibilityIQHandler.java
> JH
> org/apache/vysper/xmpp/modules/core/starttls/handler/StartTLSHandler.java
> J
> org/apache/vysper/xmpp/modules/core/starttls/StartTLSStanzaDictionary.java
> J
> org/apache/vysper/xmpp/modules/servicediscovery/ServiceDiscoveryInfoDictionary.java
> J
> org/apache/vysper/xmpp/modules/servicediscovery/collection/ServiceDiscoveryRequestListenerRegistry.java
> J
> org/apache/vysper/xmpp/modules/servicediscovery/collection/ServiceCollector.java
> J
> org/apache/vysper/xmpp/modules/servicediscovery/ServiceDiscoveryItemDictionary.java
> J
> org/apache/vysper/xmpp/modules/servicediscovery/management/ServerInfoRequestListener.java
> JH org/apache/vysper/xmpp/modules/servicediscovery/management/Item.java
> JH
> org/apache/vysper/xmpp/modules/servicediscovery/management/Feature.java
> JA
> org/apache/vysper/xmpp/modules/servicediscovery/management/InfoDataForm.java
> JH
> org/apache/vysper/xmpp/modules/servicediscovery/management/ServiceDiscoveryRequestException.java
> JH
> org/apache/vysper/xmpp/modules/servicediscovery/management/InfoElement.java
> JH
> org/apache/vysper/xmpp/modules/servicediscovery/management/InfoRequest.java
> JH
> org/apache/vysper/xmpp/modules/servicediscovery/management/Identity.java
> J
> org/apache/vysper/xmpp/modules/servicediscovery/management/InfoRequestListener.java
> J
> org/apache/vysper/xmpp/modules/servicediscovery/management/ItemRequestListener.java
> J
> org/apache/vysper/xmpp/modules/servicediscovery/handler/DiscoItemIQHandler.java
> J
> org/apache/vysper/xmpp/modules/servicediscovery/handler/DiscoInfoIQHandler.java
> J
> org/apache/vysper/xmpp/modules/servicediscovery/ServiceDiscoveryModule.java
> org/apache/vysper/xmpp/modules/DefaultModule.java
> org/apache/vysper/xmpp/modules/ModuleRegistry.java
> org/apache/vysper/xmpp/modules/Module.java
> org/apache/vysper/xmpp/modules/DefaultDiscoAwareModule.java
> JH
> org/apache/vysper/xmpp/modules/roster/persistence/AbstractRosterManager.java
> J
> org/apache/vysper/xmpp/modules/roster/persistence/MemoryRosterManager.java
> J org/apache/vysper/xmpp/modules/roster/persistence/RosterManager.java
> JH org/apache/vysper/xmpp/modules/roster/RosterUtils.java
> J org/apache/vysper/xmpp/modules/roster/SubscriptionType.java
> J org/apache/vysper/xmpp/modules/roster/Roster.java
> JH org/apache/vysper/xmpp/modules/roster/RosterGroup.java
> JH org/apache/vysper/xmpp/modules/roster/RosterStanzaUtils.java
> JH org/apache/vysper/xmpp/modules/roster/RosterBadRequestException.java
> JH org/apache/vysper/xmpp/modules/roster/RosterException.java
> J org/apache/vysper/xmpp/modules/roster/RosterModule.java
> JH org/apache/vysper/xmpp/modules/roster/MutableRoster.java
> J org/apache/vysper/xmpp/modules/roster/handler/RosterIQHandler.java
> J org/apache/vysper/xmpp/modules/roster/RosterSubscriptionMutator.java
> J org/apache/vysper/xmpp/modules/roster/RosterItem.java
> JH org/apache/vysper/xmpp/modules/roster/RosterConfiguration.java
> JH
> org/apache/vysper/xmpp/modules/roster/RosterNotAcceptableException.java
> JH org/apache/vysper/xmpp/modules/roster/AskSubscriptionType.java
> J org/apache/vysper/xmpp/modules/roster/RosterDictionary.java
> JH
> org/apache/vysper/xmpp/modules/extension/xep0092_software_version/SoftwareVersionIQHandler.java
> JH
> org/apache/vysper/xmpp/modules/extension/xep0092_software_version/SoftwareVersionModule.java
> JH
> org/apache/vysper/xmpp/modules/extension/xep0060_pubsub/PubSubPersistenceManager.java
> JH
> org/apache/vysper/xmpp/modules/extension/xep0060_pubsub/model/MultipleSubscriptionException.java
> JH
> org/apache/vysper/xmpp/modules/extension/xep0060_pubsub/model/DuplicateNodeException.java
> JH
> org/apache/vysper/xmpp/modules/extension/xep0060_pubsub/model/CollectionNode.java
> jH
> org/apache/vysper/xmpp/modules/extension/xep0060_pubsub/model/LeafNode.java
> JH
> org/apache/vysper/xmpp/modules/extension/xep0060_pubsub/SubscriberVisitor.java
> J
> org/apache/vysper/xmpp/modules/extension/xep0060_pubsub/AbstractPublishSubscribeIQHandler.java
> JH
> org/apache/vysper/xmpp/modules/extension/xep0060_pubsub/SubscriberNotificationVisitor.java
> JH
> org/apache/vysper/xmpp/modules/extension/xep0060_pubsub/handler/PubSubPublishHandler.java
> JH
> org/apache/vysper/xmpp/modules/extension/xep0060_pubsub/handler/owner/PubSubOwnerConfigureNodeHandler.java
> JH
> org/apache/vysper/xmpp/modules/extension/xep0060_pubsub/handler/owner/AbstractPubSubOwnerHandler.java
> JH
> org/apache/vysper/xmpp/modules/extension/xep0060_pubsub/handler/owner/PubSubOwnerDeleteNodeHandler.java
> JH
> org/apache/vysper/xmpp/modules/extension/xep0060_pubsub/handler/AbstractPubSubGeneralHandler.java
> JH
> org/apache/vysper/xmpp/modules/extension/xep0060_pubsub/handler/PubSubUnsubscribeHandler.java
> JH
> org/apache/vysper/xmpp/modules/extension/xep0060_pubsub/handler/PubSubCreateNodeHandler.java
> JH
> org/apache/vysper/xmpp/modules/extension/xep0060_pubsub/handler/PubSubSubscribeHandler.java
> JH
> org/apache/vysper/xmpp/modules/extension/xep0060_pubsub/NullPersistenceManager.java
> j
> org/apache/vysper/xmpp/modules/extension/xep0060_pubsub/PublishSubscribeModule.java
> JH
> org/apache/vysper/xmpp/modules/extension/xep0054_vcardtemp/VcardTempModule.java
> JH
> org/apache/vysper/xmpp/modules/extension/xep0054_vcardtemp/VcardTempPersistenceManager.java
> JH
> org/apache/vysper/xmpp/modules/extension/xep0054_vcardtemp/VcardTempIQHandler.java
> JH
> org/apache/vysper/xmpp/modules/extension/xep0202_entity_time/EntityTimeModule.java
> JH
> org/apache/vysper/xmpp/modules/extension/xep0202_entity_time/EntityTimeIQHandler.java
> J
> org/apache/vysper/xmpp/modules/extension/xep0202_entity_time/EntityTimeXEP0090IQHandler.java
> JH
> org/apache/vysper/xmpp/modules/extension/xep0049_privatedata/PrivateDataModule.java
> JH
> org/apache/vysper/xmpp/modules/extension/xep0049_privatedata/PrivateDataPersistenceManager.java
> JH
> org/apache/vysper/xmpp/modules/extension/xep0049_privatedata/PrivateDataIQHandler.java
> org/apache/vysper/xmpp/modules/ServerRuntimeContextService.java
> JH org/apache/vysper/xmpp/delivery/LocalDeliveryUtils.java
> JH org/apache/vysper/xmpp/delivery/NoSuchLocalUserException.java
> J org/apache/vysper/xmpp/delivery/StanzaRelay.java
> J org/apache/vysper/xmpp/delivery/StanzaReceiverQueue.java
> JH org/apache/vysper/xmpp/delivery/DeliveryException.java
> JH
> org/apache/vysper/xmpp/delivery/failure/ReturnErrorToSenderFailureStrategy.java
> JH org/apache/vysper/xmpp/delivery/failure/IgnoreFailureStrategy.java
> J org/apache/vysper/xmpp/delivery/DeliveringInboundStanzaRelay.java
> J org/apache/vysper/xmpp/delivery/StanzaReceiver.java
> OK org/apache/vysper/xmpp/delivery/DeliveryFailureStrategy.java
> J org/apache/vysper/xmpp/delivery/StanzaRelayBroker.java
> JA org/apache/vysper/xmpp/delivery/StanzaReceiverRelay.java
> J org/apache/vysper/xmpp/delivery/RecordingStanzaRelay.java
> JH org/apache/vysper/xmpp/delivery/LocalRecipientOfflineException.java
> org/apache/vysper/xmpp/xmlfragment/XMLFragment.java
> org/apache/vysper/xmpp/xmlfragment/NamespaceAttribute.java
> org/apache/vysper/xmpp/xmlfragment/XMLSemanticError.java
> org/apache/vysper/xmpp/xmlfragment/EqualityVerifier.java
> org/apache/vysper/xmpp/xmlfragment/FragmentFactory.java
> org/apache/vysper/xmpp/xmlfragment/XMLElementVerifier.java
> org/apache/vysper/xmpp/xmlfragment/Attribute.java
> org/apache/vysper/xmpp/xmlfragment/Renderer.java
> org/apache/vysper/xmpp/xmlfragment/XMLElement.java
> org/apache/vysper/xmpp/xmlfragment/XMLText.java
> org/apache/vysper/xmpp/parser/io/PlainToTLSStreaming.java
> org/apache/vysper/xmpp/parser/StringStreamParser.java
> org/apache/vysper/xmpp/parser/EncryptionAware.java
> org/apache/vysper/xmpp/parser/InputStreamParser.java
> org/apache/vysper/xmpp/parser/StreamParser.java
> org/apache/vysper/xmpp/parser/ParsingErrorCondition.java
> org/apache/vysper/xmpp/parser/ParsingException.java
> org/apache/vysper/xmpp/parser/AbstractNekopullStreamParser.java
> JH org/apache/vysper/xmpp/cryptography/TLSContextFactory.java
> JH org/apache/vysper/xmpp/cryptography/FileBasedTLSContextFactory.java
> J org/apache/vysper/xmpp/cryptography/AbstractTLSContextFactory.java
> J org/apache/vysper/xmpp/cryptography/BogusTrustManagerFactory.java
> JH org/apache/vysper/xmpp/cryptography/TrustManagerFactory.java
> org/apache/vysper/xmpp/server/AbstractSessionContext.java
> org/apache/vysper/xmpp/server/SessionState.java
> org/apache/vysper/xmpp/server/ServerRuntimeContext.java
> org/apache/vysper/xmpp/server/response/ServerResponses.java
> org/apache/vysper/xmpp/server/response/ServerErrorResponses.java
> org/apache/vysper/xmpp/server/DefaultServerRuntimeContext.java
> org/apache/vysper/xmpp/server/SessionContext.java
> org/apache/vysper/xmpp/server/ServerFeatures.java
> org/apache/vysper/xmpp/server/Endpoint.java
> org/apache/vysper/xmpp/server/XMPPServer.java
> org/apache/vysper/xmpp/server/XMPPVersion.java
> org/apache/vysper/xmpp/server/ServerMain.java
> org/apache/vysper/xmpp/stanza/Stanza.java
> org/apache/vysper/xmpp/stanza/MessageStanzaType.java
> org/apache/vysper/xmpp/stanza/IQStanza.java
> org/apache/vysper/xmpp/stanza/PresenceStanzaType.java
> org/apache/vysper/xmpp/stanza/dataforms/Field.java
> org/apache/vysper/xmpp/stanza/dataforms/DataFormEncoder.java
> org/apache/vysper/xmpp/stanza/dataforms/DataForm.java
> org/apache/vysper/xmpp/stanza/dataforms/Option.java
> org/apache/vysper/xmpp/stanza/IQStanzaType.java
> org/apache/vysper/xmpp/stanza/MessageStanza.java
> org/apache/vysper/xmpp/stanza/StanzaErrorType.java
> org/apache/vysper/xmpp/stanza/XMPPCoreStanza.java
> org/apache/vysper/xmpp/stanza/StanzaBuilder.java
> org/apache/vysper/xmpp/stanza/StanzaErrorCondition.java
> org/apache/vysper/xmpp/stanza/PresenceStanza.java
> org/apache/vysper/xmpp/stanza/XMPPCoreStanzaVerifier.java
> org/apache/vysper/xmpp/writer/StanzaWriter.java
> org/apache/vysper/xmpp/writer/SystemOutStanzaWriter.java
> org/apache/vysper/xmpp/writer/DenseStanzaLogRenderer.java
> org/apache/vysper/xmpp/protocol/StreamErrorCondition.java
> org/apache/vysper/xmpp/protocol/SessionStateModifier.java
> org/apache/vysper/xmpp/protocol/exception/AuthorizationFailedException.java
> org/apache/vysper/xmpp/protocol/exception/TLSException.java
> org/apache/vysper/xmpp/protocol/exception/BadXMLException.java
> org/apache/vysper/xmpp/protocol/ProtocolException.java
> org/apache/vysper/xmpp/protocol/StateAwareProtocolWorker.java
> org/apache/vysper/xmpp/protocol/ResponseWriter.java
> org/apache/vysper/xmpp/protocol/StanzaHandler.java
> org/apache/vysper/xmpp/protocol/ServiceUnavailableStanzaErrorHandler.java
> org/apache/vysper/xmpp/protocol/ResponseStanzaContainerImpl.java
> org/apache/vysper/xmpp/protocol/SessionStateHolder.java
> org/apache/vysper/xmpp/protocol/StanzaHandlerLookup.java
> org/apache/vysper/xmpp/protocol/NamespaceURIs.java
> org/apache/vysper/xmpp/protocol/QueuedStanzaProcessor.java
> org/apache/vysper/xmpp/protocol/ProtocolWorker.java
> org/apache/vysper/xmpp/protocol/NamespaceHandlerDictionary.java
> org/apache/vysper/xmpp/protocol/worker/EncryptionStartedProtocolWorker.java
> org/apache/vysper/xmpp/protocol/worker/EndOrClosedProtocolWorker.java
> org/apache/vysper/xmpp/protocol/worker/EncryptedProtocolWorker.java
> org/apache/vysper/xmpp/protocol/worker/InitiatedProtocolWorker.java
> org/apache/vysper/xmpp/protocol/worker/InboundStanzaProtocolWorker.java
>
> org/apache/vysper/xmpp/protocol/worker/AbstractStateAwareProtocolWorker.java
> org/apache/vysper/xmpp/protocol/worker/StartedProtocolWorker.java
> org/apache/vysper/xmpp/protocol/worker/AuthenticatedProtocolWorker.java
> org/apache/vysper/xmpp/protocol/worker/UnconnectedProtocolWorker.java
> org/apache/vysper/xmpp/protocol/HandlerDictionary.java
> org/apache/vysper/xmpp/protocol/StanzaProcessor.java
> org/apache/vysper/xmpp/protocol/ResponseStanzaContainer.java
> OK org/apache/vysper/compliance/SpecCompliance.java
> J
> org/apache/vysper/compliance/reporting/DocumentSpecCompliantAnnotationFactory.java
> OK org/apache/vysper/compliance/SpecCompliant.java
> JH org/apache/vysper/storage/jcr/user/JcrUserManagement.java
> JH org/apache/vysper/storage/jcr/JcrStorageException.java
> JH
> org/apache/vysper/storage/jcr/vcardtemp/JcrVcardTempPersistenceManager.java
> J org/apache/vysper/storage/jcr/JcrStorage.java
> JH org/apache/vysper/storage/jcr/JcrStorageProviderRegistry.java
> J org/apache/vysper/storage/jcr/roster/JcrRosterManager.java
> JH
> org/apache/vysper/storage/jcr/privatedata/JcrPrivateDataPersistenceManager.java
> JH org/apache/vysper/storage/StorageProviderRegistry.java
> OK org/apache/vysper/storage/StorageProvider.java
> JH org/apache/vysper/storage/OpenStorageProviderRegistry.java
> J org/apache/vysper/storage/inmemory/MemoryStorageProviderRegistry.java
> J org/apache/vysper/stanzasession/StanzaSessionContext.java
> JH org/apache/vysper/stanzasession/StanzaSession.java
> jA org/apache/vysper/stanzasession/StanzaSessionFactory.java
> JHA org/apache/vysper/spring/AddUserHelper.java
> J org/apache/vysper/spring/ResourceBasedTLSContextFactory.java
> OK org/apache/vysper/spring/ServerMain.java
> OK org/apache/vysper/charset/CharsetUtil.java
>
>
> 1 : The @author tag contain some reference to someone, but if the cade has
> been included, no reference from the original project
>
>
> --
> --
> cordialement, regards,
> Emmanuel Lécharny
> www.iktek.com
> directory.apache.org
>
>
>
--
Alex Karasulu
My Blog :: http://www.jroller.com/akarasulu/
Apache Directory Server :: http://directory.apache.org
Apache MINA :: http://mina.apache.org
Re: Move Vysper from sandbox
Posted by Emmanuel Lecharny <el...@apache.org>.
Michael Jakl wrote:
> Hi!
>
>
> The documentation I found in Vysper proved very helpful and - of course - more
> of it would do good. Anyway I'd second the view that good documentation
> shouldn't repeat what the code says best. The HTML argument is a good one, but
> IMHO more relevant in closed source projects, instead of a RTFM we have the
> option for a RTFC(ode).
>
Keep in mind that no Javadoc means no HTML documentation for the public
API...
Just ask yourself when you are in front of a class you just wrote : what
if the user read the HTML generated page and get something like :
http://mina.apache.org/report/trunk/apidocs/org/apache/mina/integration/xbean/StandardThreadPool.html
How useful is this ?
>
> Maybe a quick dependency graph could show us the "hotspots" which are the
> classes many others use/depend on - these are the ones which need good
> documentation, I'd guess.
>
Well, don't loose time on checking files one by one as I did. An easier
way to immediately realize what need to be done is to generate the
Javadoc HTML file and watch it. I don't know why I didn't thought about
it before ...
> Cheers,
> Michael
>
> PS: If the code and the comments disagree, then both are probably wrong.
>
Ah ah ah ! Excellent ;)
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: Move Vysper from sandbox
Posted by Alex Karasulu <ak...@gmail.com>.
On Sun, Jun 21, 2009 at 6:57 PM, Michael Jakl <ja...@gmail.com>wrote:
> Hi!
>
> On Sun, Jun 21, 2009 at 23:04, Emmanuel Lecharny<el...@apache.org>
> wrote:
> >> I have to admit that this kind of quantitive analysis doesn't tell me
> >> much. I'd rather improve the javadoc for a central class than write a
> >> new one for a simple interface setter method where the name and
> >> parameters speak for themselves.
> >>
> >
> [...]
> >
> > I don't like over documented code, for instance (I mean, comments
> *inside*
> > the code). Just because if you needed to add some comments in your code,
> > that means your code is probably too complex to be understood by a normal
> > human being (ie , the 'average programmer' ;), and you may have to split
> the
> > code a bit. The very same applies for naming. Not being english native
> > speakers make it difficult to use the exact correct name for a field or a
> > function.
>
> The documentation I found in Vysper proved very helpful and - of course -
> more
> of it would do good. Anyway I'd second the view that good documentation
> shouldn't repeat what the code says best. The HTML argument is a good one,
> but
> IMHO more relevant in closed source projects, instead of a RTFM we have the
> option for a RTFC(ode).
>
> >>
> >> But if you point out critical code that misses a javadoc, unit test or
> >> spec compliance annotation or code comment, you'll never find me
> >> disagreeing with you. (I reserve the right to ask for a patch, though.
> ;-)
> >>
> >
> > As a general politic, I think that the one who write the code at first is
> > the one who *knows*. Hopefully, modern IDE generates all this boring
> Javadoc
> > for setters and getters. Otherwise, I don't think that adding headers for
> > private method is always mandatory (sometime it helps). It's all about
> how
> > easy it is to understand what a method do. However, what seems easy for
> you
> > might be a bit more complicated for someone just diving into your code.
> >
> > I personally find it polite to add headers and javadoc, it makes the code
> > more welcoming. Like names for the street and number on the doors.
> >>
> >> So my question is, where is that code which most deserves being improved
> >> in this way?
> >>
> >
> > Well, without having done the quality analysis yet, my answer, not a
> > surprise, will be : all the interface and public methods without Javadoc
> ;)
> > Very PC, I know ...
> >
> > But as this is not the answer you are expecting, so give me a couple of
> > week, if I can find the time to dive into the code.
>
> I think Emmanuel touched the essence of the discussion a few paragraphs
> earlier: "the one who wrote the code knows what to document". So not
> surprising
> I'm adding "Javadoc for PubSub-related classes" to my todo list :)
>
> Maybe a quick dependency graph could show us the "hotspots" which are the
> classes many others use/depend on - these are the ones which need good
> documentation, I'd guess.
>
Very good point for identifying the code to document best based on a
80/20-like principal to documentation. I really like this idea Michael!
Alex
--
Alex Karasulu
My Blog :: http://www.jroller.com/akarasulu/
Apache Directory Server :: http://directory.apache.org
Apache MINA :: http://mina.apache.org
Re: Move Vysper from sandbox
Posted by Michael Jakl <ja...@gmail.com>.
Hi!
On Sun, Jun 21, 2009 at 23:04, Emmanuel Lecharny<el...@apache.org> wrote:
>> I have to admit that this kind of quantitive analysis doesn't tell me
>> much. I'd rather improve the javadoc for a central class than write a
>> new one for a simple interface setter method where the name and
>> parameters speak for themselves.
>>
>
[...]
>
> I don't like over documented code, for instance (I mean, comments *inside*
> the code). Just because if you needed to add some comments in your code,
> that means your code is probably too complex to be understood by a normal
> human being (ie , the 'average programmer' ;), and you may have to split the
> code a bit. The very same applies for naming. Not being english native
> speakers make it difficult to use the exact correct name for a field or a
> function.
The documentation I found in Vysper proved very helpful and - of course - more
of it would do good. Anyway I'd second the view that good documentation
shouldn't repeat what the code says best. The HTML argument is a good one, but
IMHO more relevant in closed source projects, instead of a RTFM we have the
option for a RTFC(ode).
>>
>> But if you point out critical code that misses a javadoc, unit test or
>> spec compliance annotation or code comment, you'll never find me
>> disagreeing with you. (I reserve the right to ask for a patch, though. ;-)
>>
>
> As a general politic, I think that the one who write the code at first is
> the one who *knows*. Hopefully, modern IDE generates all this boring Javadoc
> for setters and getters. Otherwise, I don't think that adding headers for
> private method is always mandatory (sometime it helps). It's all about how
> easy it is to understand what a method do. However, what seems easy for you
> might be a bit more complicated for someone just diving into your code.
>
> I personally find it polite to add headers and javadoc, it makes the code
> more welcoming. Like names for the street and number on the doors.
>>
>> So my question is, where is that code which most deserves being improved
>> in this way?
>>
>
> Well, without having done the quality analysis yet, my answer, not a
> surprise, will be : all the interface and public methods without Javadoc ;)
> Very PC, I know ...
>
> But as this is not the answer you are expecting, so give me a couple of
> week, if I can find the time to dive into the code.
I think Emmanuel touched the essence of the discussion a few paragraphs
earlier: "the one who wrote the code knows what to document". So not surprising
I'm adding "Javadoc for PubSub-related classes" to my todo list :)
Maybe a quick dependency graph could show us the "hotspots" which are the
classes many others use/depend on - these are the ones which need good
documentation, I'd guess.
Cheers,
Michael
PS: If the code and the comments disagree, then both are probably wrong.
-- Norm Schryer
Re: Move Vysper from sandbox
Posted by Emmanuel Lecharny <el...@apache.org>.
Bernd Fondermann wrote:
> Emmanuel Lecharny wrote:
>
>> Bernd Fondermann wrote:
>>
>>> To turn this into an actually task, could you point out areas/classes
>>> that especially lack javadoc?
>>>
>>>
>> I have conducted a quick review of around one third of the java files
>> (test excluded). I have tagged all the files I reviewed with :
>> * J : files without javadoc
>> * j : files with partial Javadoc
>> * H : files without a description in the header
>> * A : missing @author tag
>> * OK : files with all the needed javadoc, header and @author tag
>>
>> Some of them combine mor ethan one of those missing elements.
>>
>> I have found only 8 OK files oit of 96 files I checked. Here is the list
>> (files without one of those tags haven't be checked yet)
>>
>> Note that I may have been inaccurate to some extent.
>>
>
> Probably not, thanks for putting this together.
>
> I have to admit that this kind of quantitive analysis doesn't tell me
> much. I'd rather improve the javadoc for a central class than write a
> new one for a simple interface setter method where the name and
> parameters speak for themselves.
>
Quantity... Sounds like an enemy of Quality :) Being an old fart, and a
bit rigid too, as a rule of thumb (not talking about Vysper here), all
the crappy programs I had to deal with *always* had crappy - or missing
doco. On the other side, doco all over the code never indicate any level
of Quality.
Here, I would like to get out of this Quantity vs Quality debate,
because it's a dead end. My POV is that documented program is always
easier to understand by new comers. Another aspect is that whatever you
do, you won't be the maintainer of the code you write forever, so better
think about the next guy, something like 'write code for the average
programmer'.
I don't like over documented code, for instance (I mean, comments
*inside* the code). Just because if you needed to add some comments in
your code, that means your code is probably too complex to be understood
by a normal human being (ie , the 'average programmer' ;), and you may
have to split the code a bit. The very same applies for naming. Not
being english native speakers make it difficult to use the exact correct
name for a field or a function.
Now, that does not apply for Javadoc, as it's intended to be exported to
produce some cool HTML pages someone may look at occasionally (when you
send the guy a RTFM for instance ;)
> (I started programming when CPUs where slow, RAM was sparse and the
> significant characters of a variable that were recognized by the
> compiler were limited to the first 12 or so.
> Today, we have code completion and no shortage of method or variable
> name lengths. I try to make heavy use of that.)
>
Talk to me about that !!! When I started writing code, it's was either
basic or assembly langage (Z80, 8080 or 6502). My first computer was
having 16 Kbytes (yeah, kilo !). I even had to *count* cpu cycles for
each operation to know how long the program will take... It was back in
1982 (I'm not talking about my old TI57 with 49 program steps (ie, 49
*bytes* of memory ...)
Sometime you just have to remember where you came from to see how
pleasant this present time is !
> It's like your total unit test coverage number. It doesn't tell you
> anything about your test quality.
>
Absolutely.
> But if you point out critical code that misses a javadoc, unit test or
> spec compliance annotation or code comment, you'll never find me
> disagreeing with you. (I reserve the right to ask for a patch, though. ;-)
>
As a general politic, I think that the one who write the code at first
is the one who *knows*. Hopefully, modern IDE generates all this boring
Javadoc for setters and getters. Otherwise, I don't think that adding
headers for private method is always mandatory (sometime it helps). It's
all about how easy it is to understand what a method do. However, what
seems easy for you might be a bit more complicated for someone just
diving into your code.
I personally find it polite to add headers and javadoc, it makes the
code more welcoming. Like names for the street and number on the doors.
> So my question is, where is that code which most deserves being improved
> in this way?
>
Well, without having done the quality analysis yet, my answer, not a
surprise, will be : all the interface and public methods without Javadoc
;) Very PC, I know ...
But as this is not the answer you are expecting, so give me a couple of
week, if I can find the time to dive into the code.
Thanks !
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: Move Vysper from sandbox
Posted by Bernd Fondermann <bf...@brainlounge.de>.
Emmanuel Lecharny wrote:
> Bernd Fondermann wrote:
>> To turn this into an actually task, could you point out areas/classes
>> that especially lack javadoc?
>>
> I have conducted a quick review of around one third of the java files
> (test excluded). I have tagged all the files I reviewed with :
> * J : files without javadoc
> * j : files with partial Javadoc
> * H : files without a description in the header
> * A : missing @author tag
> * OK : files with all the needed javadoc, header and @author tag
>
> Some of them combine mor ethan one of those missing elements.
>
> I have found only 8 OK files oit of 96 files I checked. Here is the list
> (files without one of those tags haven't be checked yet)
>
> Note that I may have been inaccurate to some extent.
Probably not, thanks for putting this together.
I have to admit that this kind of quantitive analysis doesn't tell me
much. I'd rather improve the javadoc for a central class than write a
new one for a simple interface setter method where the name and
parameters speak for themselves.
(I started programming when CPUs where slow, RAM was sparse and the
significant characters of a variable that were recognized by the
compiler were limited to the first 12 or so.
Today, we have code completion and no shortage of method or variable
name lengths. I try to make heavy use of that.)
It's like your total unit test coverage number. It doesn't tell you
anything about your test quality.
But if you point out critical code that misses a javadoc, unit test or
spec compliance annotation or code comment, you'll never find me
disagreeing with you. (I reserve the right to ask for a patch, though. ;-)
So my question is, where is that code which most deserves being improved
in this way?
Bernd
>
>
>
> J org/apache/vysper/mina/MinaBackedSessionContext.java
> JH org/apache/vysper/mina/XmppIoHandlerAdapter.java
> J org/apache/vysper/mina/TCPEndpoint.java
> J org/apache/vysper/mina/codec/XMLStreamTokenizer.java
> J org/apache/vysper/mina/codec/StanzaWriteInfo.java
> J org/apache/vysper/mina/codec/XMPPProtocolCodecFactory.java
> J org/apache/vysper/mina/codec/StanzaWriterProtocolEncoder.java
> org/apache/vysper/xmpp/uuid/UUIDGenerator.java
> org/apache/vysper/xmpp/uuid/JVMBuiltinUUIDGenerator.java
> org/apache/vysper/xmpp/xmldecoder/UnsupportedXMLException.java
> org/apache/vysper/xmpp/xmldecoder/DecodingException.java
> org/apache/vysper/xmpp/xmldecoder/XMLParticle.java
> org/apache/vysper/xmpp/xmldecoder/XMLRawToFragmentConverter.java
> org/apache/vysper/xmpp/xmldecoder/ParticleDecoder.java
> JA org/apache/vysper/xmpp/datetime/DateTimeProfile.java
> org/apache/vysper/xmpp/state/resourcebinding/ResourceRegistry.java
> org/apache/vysper/xmpp/state/resourcebinding/ResourceState.java
> org/apache/vysper/xmpp/state/resourcebinding/BindException.java
> org/apache/vysper/xmpp/state/presence/LatestPresenceCache.java
> org/apache/vysper/xmpp/state/presence/SimplePresenceCache.java
> org/apache/vysper/xmpp/state/presence/PresenceCachingException.java
> J org/apache/vysper/xmpp/authorization/External.java
> OK org/apache/vysper/xmpp/authorization/UserAuthorization.java
> J org/apache/vysper/xmpp/authorization/SimpleUserAuthorization.java
> JH org/apache/vysper/xmpp/authorization/AccountCreationException.java
> H org/apache/vysper/xmpp/authorization/AccountManagement.java
> J org/apache/vysper/xmpp/authorization/Anonymous.java
> J org/apache/vysper/xmpp/authorization/AuthorizationResponses.java
> J org/apache/vysper/xmpp/authorization/Plain.java
> OK org/apache/vysper/xmpp/authorization/SASLMechanism.java
> JH org/apache/vysper/xmpp/addressing/EntityFormatException.java
> A1 org/apache/vysper/xmpp/addressing/stringprep/StringPrepConstants.java
> jA1 org/apache/vysper/xmpp/addressing/stringprep/StringPrep.java
> JA1H
> org/apache/vysper/xmpp/addressing/stringprep/StringPrepViolationException.java
>
> ja1 org/apache/vysper/xmpp/addressing/stringprep/ResourcePrep.java
> ja1 org/apache/vysper/xmpp/addressing/stringprep/NodePrep.java
> J org/apache/vysper/xmpp/addressing/Entity.java
> J org/apache/vysper/xmpp/addressing/EntityImpl.java
> JH org/apache/vysper/xmpp/addressing/EntityConformance.java
> J
> org/apache/vysper/xmpp/modules/core/im/handler/PresenceAvailabilityHandler.java
>
> J org/apache/vysper/xmpp/modules/core/im/handler/PresenceHandler.java
> J
> org/apache/vysper/xmpp/modules/core/im/handler/PresenceSubscriptionHandler.java
>
> JH
> org/apache/vysper/xmpp/modules/core/im/handler/AbstractPresenceSpecializedHandler.java
>
> J
> org/apache/vysper/xmpp/modules/core/base/BaseStreamStanzaDictionary.java
> J
> org/apache/vysper/xmpp/modules/core/base/handler/DefaultIQHandler.java
> h
> org/apache/vysper/xmpp/modules/core/base/handler/async/RunnableFuture.java
> J
> org/apache/vysper/xmpp/modules/core/base/handler/async/ResponseFuture.java
> j
> org/apache/vysper/xmpp/modules/core/base/handler/async/AbstractAsyncIQGetHandler.java
>
> J org/apache/vysper/xmpp/modules/core/base/handler/IQHandler.java
> JH
> org/apache/vysper/xmpp/modules/core/base/handler/StreamStartHandler.java
> J
> org/apache/vysper/xmpp/modules/core/base/handler/XMPPCoreStanzaHandler.java
> J org/apache/vysper/xmpp/modules/core/base/handler/MessageHandler.java
> JH
> org/apache/vysper/xmpp/modules/core/base/handler/XMLPrologHandler.java
> J org/apache/vysper/xmpp/modules/core/bind/handler/BindIQHandler.java
> J org/apache/vysper/xmpp/modules/core/bind/BindResourceDictionary.java
> J
> org/apache/vysper/xmpp/modules/core/sasl/AuthorizationRetriesCounter.java
> J org/apache/vysper/xmpp/modules/core/sasl/SASLFailureType.java
> J org/apache/vysper/xmpp/modules/core/sasl/SASLStanzaDictionary.java
> JH org/apache/vysper/xmpp/modules/core/sasl/handler/AuthHandler.java
> JH
> org/apache/vysper/xmpp/modules/core/sasl/handler/AbstractSASLHandler.java
> JH org/apache/vysper/xmpp/modules/core/sasl/handler/AbortHandler.java
> J
> org/apache/vysper/xmpp/modules/core/session/SessionStanzaDictionary.java
> J
> org/apache/vysper/xmpp/modules/core/session/handler/SessionIQHandler.java
> J
> org/apache/vysper/xmpp/modules/core/compatibility/jabber_iq_auth/JabberIQAuthDictionary.java
>
> J
> org/apache/vysper/xmpp/modules/core/compatibility/jabber_iq_auth/handler/AuthCompatibilityIQHandler.java
>
> JH
> org/apache/vysper/xmpp/modules/core/starttls/handler/StartTLSHandler.java
> J
> org/apache/vysper/xmpp/modules/core/starttls/StartTLSStanzaDictionary.java
> J
> org/apache/vysper/xmpp/modules/servicediscovery/ServiceDiscoveryInfoDictionary.java
>
> J
> org/apache/vysper/xmpp/modules/servicediscovery/collection/ServiceDiscoveryRequestListenerRegistry.java
>
> J
> org/apache/vysper/xmpp/modules/servicediscovery/collection/ServiceCollector.java
>
> J
> org/apache/vysper/xmpp/modules/servicediscovery/ServiceDiscoveryItemDictionary.java
>
> J
> org/apache/vysper/xmpp/modules/servicediscovery/management/ServerInfoRequestListener.java
>
> JH org/apache/vysper/xmpp/modules/servicediscovery/management/Item.java
> JH
> org/apache/vysper/xmpp/modules/servicediscovery/management/Feature.java
> JA
> org/apache/vysper/xmpp/modules/servicediscovery/management/InfoDataForm.java
>
> JH
> org/apache/vysper/xmpp/modules/servicediscovery/management/ServiceDiscoveryRequestException.java
>
> JH
> org/apache/vysper/xmpp/modules/servicediscovery/management/InfoElement.java
> JH
> org/apache/vysper/xmpp/modules/servicediscovery/management/InfoRequest.java
> JH
> org/apache/vysper/xmpp/modules/servicediscovery/management/Identity.java
> J
> org/apache/vysper/xmpp/modules/servicediscovery/management/InfoRequestListener.java
>
> J
> org/apache/vysper/xmpp/modules/servicediscovery/management/ItemRequestListener.java
>
> J
> org/apache/vysper/xmpp/modules/servicediscovery/handler/DiscoItemIQHandler.java
>
> J
> org/apache/vysper/xmpp/modules/servicediscovery/handler/DiscoInfoIQHandler.java
>
> J
> org/apache/vysper/xmpp/modules/servicediscovery/ServiceDiscoveryModule.java
> org/apache/vysper/xmpp/modules/DefaultModule.java
> org/apache/vysper/xmpp/modules/ModuleRegistry.java
> org/apache/vysper/xmpp/modules/Module.java
> org/apache/vysper/xmpp/modules/DefaultDiscoAwareModule.java
> JH
> org/apache/vysper/xmpp/modules/roster/persistence/AbstractRosterManager.java
>
> J
> org/apache/vysper/xmpp/modules/roster/persistence/MemoryRosterManager.java
> J org/apache/vysper/xmpp/modules/roster/persistence/RosterManager.java
> JH org/apache/vysper/xmpp/modules/roster/RosterUtils.java
> J org/apache/vysper/xmpp/modules/roster/SubscriptionType.java
> J org/apache/vysper/xmpp/modules/roster/Roster.java
> JH org/apache/vysper/xmpp/modules/roster/RosterGroup.java
> JH org/apache/vysper/xmpp/modules/roster/RosterStanzaUtils.java
> JH org/apache/vysper/xmpp/modules/roster/RosterBadRequestException.java
> JH org/apache/vysper/xmpp/modules/roster/RosterException.java
> J org/apache/vysper/xmpp/modules/roster/RosterModule.java
> JH org/apache/vysper/xmpp/modules/roster/MutableRoster.java
> J org/apache/vysper/xmpp/modules/roster/handler/RosterIQHandler.java
> J org/apache/vysper/xmpp/modules/roster/RosterSubscriptionMutator.java
> J org/apache/vysper/xmpp/modules/roster/RosterItem.java
> JH org/apache/vysper/xmpp/modules/roster/RosterConfiguration.java
> JH
> org/apache/vysper/xmpp/modules/roster/RosterNotAcceptableException.java
> JH org/apache/vysper/xmpp/modules/roster/AskSubscriptionType.java
> J org/apache/vysper/xmpp/modules/roster/RosterDictionary.java
> JH
> org/apache/vysper/xmpp/modules/extension/xep0092_software_version/SoftwareVersionIQHandler.java
>
> JH
> org/apache/vysper/xmpp/modules/extension/xep0092_software_version/SoftwareVersionModule.java
>
> JH
> org/apache/vysper/xmpp/modules/extension/xep0060_pubsub/PubSubPersistenceManager.java
>
> JH
> org/apache/vysper/xmpp/modules/extension/xep0060_pubsub/model/MultipleSubscriptionException.java
>
> JH
> org/apache/vysper/xmpp/modules/extension/xep0060_pubsub/model/DuplicateNodeException.java
>
> JH
> org/apache/vysper/xmpp/modules/extension/xep0060_pubsub/model/CollectionNode.java
>
> jH
> org/apache/vysper/xmpp/modules/extension/xep0060_pubsub/model/LeafNode.java
> JH
> org/apache/vysper/xmpp/modules/extension/xep0060_pubsub/SubscriberVisitor.java
>
> J
> org/apache/vysper/xmpp/modules/extension/xep0060_pubsub/AbstractPublishSubscribeIQHandler.java
>
> JH
> org/apache/vysper/xmpp/modules/extension/xep0060_pubsub/SubscriberNotificationVisitor.java
>
> JH
> org/apache/vysper/xmpp/modules/extension/xep0060_pubsub/handler/PubSubPublishHandler.java
>
> JH
> org/apache/vysper/xmpp/modules/extension/xep0060_pubsub/handler/owner/PubSubOwnerConfigureNodeHandler.java
>
> JH
> org/apache/vysper/xmpp/modules/extension/xep0060_pubsub/handler/owner/AbstractPubSubOwnerHandler.java
>
> JH
> org/apache/vysper/xmpp/modules/extension/xep0060_pubsub/handler/owner/PubSubOwnerDeleteNodeHandler.java
>
> JH
> org/apache/vysper/xmpp/modules/extension/xep0060_pubsub/handler/AbstractPubSubGeneralHandler.java
>
> JH
> org/apache/vysper/xmpp/modules/extension/xep0060_pubsub/handler/PubSubUnsubscribeHandler.java
>
> JH
> org/apache/vysper/xmpp/modules/extension/xep0060_pubsub/handler/PubSubCreateNodeHandler.java
>
> JH
> org/apache/vysper/xmpp/modules/extension/xep0060_pubsub/handler/PubSubSubscribeHandler.java
>
> JH
> org/apache/vysper/xmpp/modules/extension/xep0060_pubsub/NullPersistenceManager.java
>
> j
> org/apache/vysper/xmpp/modules/extension/xep0060_pubsub/PublishSubscribeModule.java
>
> JH
> org/apache/vysper/xmpp/modules/extension/xep0054_vcardtemp/VcardTempModule.java
>
> JH
> org/apache/vysper/xmpp/modules/extension/xep0054_vcardtemp/VcardTempPersistenceManager.java
>
> JH
> org/apache/vysper/xmpp/modules/extension/xep0054_vcardtemp/VcardTempIQHandler.java
>
> JH
> org/apache/vysper/xmpp/modules/extension/xep0202_entity_time/EntityTimeModule.java
>
> JH
> org/apache/vysper/xmpp/modules/extension/xep0202_entity_time/EntityTimeIQHandler.java
>
> J
> org/apache/vysper/xmpp/modules/extension/xep0202_entity_time/EntityTimeXEP0090IQHandler.java
>
> JH
> org/apache/vysper/xmpp/modules/extension/xep0049_privatedata/PrivateDataModule.java
>
> JH
> org/apache/vysper/xmpp/modules/extension/xep0049_privatedata/PrivateDataPersistenceManager.java
>
> JH
> org/apache/vysper/xmpp/modules/extension/xep0049_privatedata/PrivateDataIQHandler.java
>
> org/apache/vysper/xmpp/modules/ServerRuntimeContextService.java
> JH org/apache/vysper/xmpp/delivery/LocalDeliveryUtils.java
> JH org/apache/vysper/xmpp/delivery/NoSuchLocalUserException.java
> J org/apache/vysper/xmpp/delivery/StanzaRelay.java
> J org/apache/vysper/xmpp/delivery/StanzaReceiverQueue.java
> JH org/apache/vysper/xmpp/delivery/DeliveryException.java
> JH
> org/apache/vysper/xmpp/delivery/failure/ReturnErrorToSenderFailureStrategy.java
>
> JH org/apache/vysper/xmpp/delivery/failure/IgnoreFailureStrategy.java
> J org/apache/vysper/xmpp/delivery/DeliveringInboundStanzaRelay.java
> J org/apache/vysper/xmpp/delivery/StanzaReceiver.java
> OK org/apache/vysper/xmpp/delivery/DeliveryFailureStrategy.java
> J org/apache/vysper/xmpp/delivery/StanzaRelayBroker.java
> JA org/apache/vysper/xmpp/delivery/StanzaReceiverRelay.java
> J org/apache/vysper/xmpp/delivery/RecordingStanzaRelay.java
> JH org/apache/vysper/xmpp/delivery/LocalRecipientOfflineException.java
> org/apache/vysper/xmpp/xmlfragment/XMLFragment.java
> org/apache/vysper/xmpp/xmlfragment/NamespaceAttribute.java
> org/apache/vysper/xmpp/xmlfragment/XMLSemanticError.java
> org/apache/vysper/xmpp/xmlfragment/EqualityVerifier.java
> org/apache/vysper/xmpp/xmlfragment/FragmentFactory.java
> org/apache/vysper/xmpp/xmlfragment/XMLElementVerifier.java
> org/apache/vysper/xmpp/xmlfragment/Attribute.java
> org/apache/vysper/xmpp/xmlfragment/Renderer.java
> org/apache/vysper/xmpp/xmlfragment/XMLElement.java
> org/apache/vysper/xmpp/xmlfragment/XMLText.java
> org/apache/vysper/xmpp/parser/io/PlainToTLSStreaming.java
> org/apache/vysper/xmpp/parser/StringStreamParser.java
> org/apache/vysper/xmpp/parser/EncryptionAware.java
> org/apache/vysper/xmpp/parser/InputStreamParser.java
> org/apache/vysper/xmpp/parser/StreamParser.java
> org/apache/vysper/xmpp/parser/ParsingErrorCondition.java
> org/apache/vysper/xmpp/parser/ParsingException.java
> org/apache/vysper/xmpp/parser/AbstractNekopullStreamParser.java
> JH org/apache/vysper/xmpp/cryptography/TLSContextFactory.java
> JH org/apache/vysper/xmpp/cryptography/FileBasedTLSContextFactory.java
> J org/apache/vysper/xmpp/cryptography/AbstractTLSContextFactory.java
> J org/apache/vysper/xmpp/cryptography/BogusTrustManagerFactory.java
> JH org/apache/vysper/xmpp/cryptography/TrustManagerFactory.java
> org/apache/vysper/xmpp/server/AbstractSessionContext.java
> org/apache/vysper/xmpp/server/SessionState.java
> org/apache/vysper/xmpp/server/ServerRuntimeContext.java
> org/apache/vysper/xmpp/server/response/ServerResponses.java
> org/apache/vysper/xmpp/server/response/ServerErrorResponses.java
> org/apache/vysper/xmpp/server/DefaultServerRuntimeContext.java
> org/apache/vysper/xmpp/server/SessionContext.java
> org/apache/vysper/xmpp/server/ServerFeatures.java
> org/apache/vysper/xmpp/server/Endpoint.java
> org/apache/vysper/xmpp/server/XMPPServer.java
> org/apache/vysper/xmpp/server/XMPPVersion.java
> org/apache/vysper/xmpp/server/ServerMain.java
> org/apache/vysper/xmpp/stanza/Stanza.java
> org/apache/vysper/xmpp/stanza/MessageStanzaType.java
> org/apache/vysper/xmpp/stanza/IQStanza.java
> org/apache/vysper/xmpp/stanza/PresenceStanzaType.java
> org/apache/vysper/xmpp/stanza/dataforms/Field.java
> org/apache/vysper/xmpp/stanza/dataforms/DataFormEncoder.java
> org/apache/vysper/xmpp/stanza/dataforms/DataForm.java
> org/apache/vysper/xmpp/stanza/dataforms/Option.java
> org/apache/vysper/xmpp/stanza/IQStanzaType.java
> org/apache/vysper/xmpp/stanza/MessageStanza.java
> org/apache/vysper/xmpp/stanza/StanzaErrorType.java
> org/apache/vysper/xmpp/stanza/XMPPCoreStanza.java
> org/apache/vysper/xmpp/stanza/StanzaBuilder.java
> org/apache/vysper/xmpp/stanza/StanzaErrorCondition.java
> org/apache/vysper/xmpp/stanza/PresenceStanza.java
> org/apache/vysper/xmpp/stanza/XMPPCoreStanzaVerifier.java
> org/apache/vysper/xmpp/writer/StanzaWriter.java
> org/apache/vysper/xmpp/writer/SystemOutStanzaWriter.java
> org/apache/vysper/xmpp/writer/DenseStanzaLogRenderer.java
> org/apache/vysper/xmpp/protocol/StreamErrorCondition.java
> org/apache/vysper/xmpp/protocol/SessionStateModifier.java
> org/apache/vysper/xmpp/protocol/exception/AuthorizationFailedException.java
> org/apache/vysper/xmpp/protocol/exception/TLSException.java
> org/apache/vysper/xmpp/protocol/exception/BadXMLException.java
> org/apache/vysper/xmpp/protocol/ProtocolException.java
> org/apache/vysper/xmpp/protocol/StateAwareProtocolWorker.java
> org/apache/vysper/xmpp/protocol/ResponseWriter.java
> org/apache/vysper/xmpp/protocol/StanzaHandler.java
> org/apache/vysper/xmpp/protocol/ServiceUnavailableStanzaErrorHandler.java
> org/apache/vysper/xmpp/protocol/ResponseStanzaContainerImpl.java
> org/apache/vysper/xmpp/protocol/SessionStateHolder.java
> org/apache/vysper/xmpp/protocol/StanzaHandlerLookup.java
> org/apache/vysper/xmpp/protocol/NamespaceURIs.java
> org/apache/vysper/xmpp/protocol/QueuedStanzaProcessor.java
> org/apache/vysper/xmpp/protocol/ProtocolWorker.java
> org/apache/vysper/xmpp/protocol/NamespaceHandlerDictionary.java
> org/apache/vysper/xmpp/protocol/worker/EncryptionStartedProtocolWorker.java
> org/apache/vysper/xmpp/protocol/worker/EndOrClosedProtocolWorker.java
> org/apache/vysper/xmpp/protocol/worker/EncryptedProtocolWorker.java
> org/apache/vysper/xmpp/protocol/worker/InitiatedProtocolWorker.java
> org/apache/vysper/xmpp/protocol/worker/InboundStanzaProtocolWorker.java
> org/apache/vysper/xmpp/protocol/worker/AbstractStateAwareProtocolWorker.java
>
> org/apache/vysper/xmpp/protocol/worker/StartedProtocolWorker.java
> org/apache/vysper/xmpp/protocol/worker/AuthenticatedProtocolWorker.java
> org/apache/vysper/xmpp/protocol/worker/UnconnectedProtocolWorker.java
> org/apache/vysper/xmpp/protocol/HandlerDictionary.java
> org/apache/vysper/xmpp/protocol/StanzaProcessor.java
> org/apache/vysper/xmpp/protocol/ResponseStanzaContainer.java
> OK org/apache/vysper/compliance/SpecCompliance.java
> J
> org/apache/vysper/compliance/reporting/DocumentSpecCompliantAnnotationFactory.java
>
> OK org/apache/vysper/compliance/SpecCompliant.java
> JH org/apache/vysper/storage/jcr/user/JcrUserManagement.java
> JH org/apache/vysper/storage/jcr/JcrStorageException.java
> JH
> org/apache/vysper/storage/jcr/vcardtemp/JcrVcardTempPersistenceManager.java
> J org/apache/vysper/storage/jcr/JcrStorage.java
> JH org/apache/vysper/storage/jcr/JcrStorageProviderRegistry.java
> J org/apache/vysper/storage/jcr/roster/JcrRosterManager.java
> JH
> org/apache/vysper/storage/jcr/privatedata/JcrPrivateDataPersistenceManager.java
>
> JH org/apache/vysper/storage/StorageProviderRegistry.java
> OK org/apache/vysper/storage/StorageProvider.java
> JH org/apache/vysper/storage/OpenStorageProviderRegistry.java
> J org/apache/vysper/storage/inmemory/MemoryStorageProviderRegistry.java
> J org/apache/vysper/stanzasession/StanzaSessionContext.java
> JH org/apache/vysper/stanzasession/StanzaSession.java
> jA org/apache/vysper/stanzasession/StanzaSessionFactory.java
> JHA org/apache/vysper/spring/AddUserHelper.java
> J org/apache/vysper/spring/ResourceBasedTLSContextFactory.java
> OK org/apache/vysper/spring/ServerMain.java
> OK org/apache/vysper/charset/CharsetUtil.java
>
>
> 1 : The @author tag contain some reference to someone, but if the cade
> has been included, no reference from the original project
>
Re: Move Vysper from sandbox
Posted by Emmanuel Lecharny <el...@apache.org>.
Bernd Fondermann wrote:
> To turn this into an actually task, could you point out areas/classes
> that especially lack javadoc?
>
I have conducted a quick review of around one third of the java files
(test excluded). I have tagged all the files I reviewed with :
* J : files without javadoc
* j : files with partial Javadoc
* H : files without a description in the header
* A : missing @author tag
* OK : files with all the needed javadoc, header and @author tag
Some of them combine mor ethan one of those missing elements.
I have found only 8 OK files oit of 96 files I checked. Here is the list
(files without one of those tags haven't be checked yet)
Note that I may have been inaccurate to some extent.
J org/apache/vysper/mina/MinaBackedSessionContext.java
JH org/apache/vysper/mina/XmppIoHandlerAdapter.java
J org/apache/vysper/mina/TCPEndpoint.java
J org/apache/vysper/mina/codec/XMLStreamTokenizer.java
J org/apache/vysper/mina/codec/StanzaWriteInfo.java
J org/apache/vysper/mina/codec/XMPPProtocolCodecFactory.java
J org/apache/vysper/mina/codec/StanzaWriterProtocolEncoder.java
org/apache/vysper/xmpp/uuid/UUIDGenerator.java
org/apache/vysper/xmpp/uuid/JVMBuiltinUUIDGenerator.java
org/apache/vysper/xmpp/xmldecoder/UnsupportedXMLException.java
org/apache/vysper/xmpp/xmldecoder/DecodingException.java
org/apache/vysper/xmpp/xmldecoder/XMLParticle.java
org/apache/vysper/xmpp/xmldecoder/XMLRawToFragmentConverter.java
org/apache/vysper/xmpp/xmldecoder/ParticleDecoder.java
JA org/apache/vysper/xmpp/datetime/DateTimeProfile.java
org/apache/vysper/xmpp/state/resourcebinding/ResourceRegistry.java
org/apache/vysper/xmpp/state/resourcebinding/ResourceState.java
org/apache/vysper/xmpp/state/resourcebinding/BindException.java
org/apache/vysper/xmpp/state/presence/LatestPresenceCache.java
org/apache/vysper/xmpp/state/presence/SimplePresenceCache.java
org/apache/vysper/xmpp/state/presence/PresenceCachingException.java
J org/apache/vysper/xmpp/authorization/External.java
OK org/apache/vysper/xmpp/authorization/UserAuthorization.java
J org/apache/vysper/xmpp/authorization/SimpleUserAuthorization.java
JH org/apache/vysper/xmpp/authorization/AccountCreationException.java
H org/apache/vysper/xmpp/authorization/AccountManagement.java
J org/apache/vysper/xmpp/authorization/Anonymous.java
J org/apache/vysper/xmpp/authorization/AuthorizationResponses.java
J org/apache/vysper/xmpp/authorization/Plain.java
OK org/apache/vysper/xmpp/authorization/SASLMechanism.java
JH org/apache/vysper/xmpp/addressing/EntityFormatException.java
A1 org/apache/vysper/xmpp/addressing/stringprep/StringPrepConstants.java
jA1 org/apache/vysper/xmpp/addressing/stringprep/StringPrep.java
JA1H
org/apache/vysper/xmpp/addressing/stringprep/StringPrepViolationException.java
ja1 org/apache/vysper/xmpp/addressing/stringprep/ResourcePrep.java
ja1 org/apache/vysper/xmpp/addressing/stringprep/NodePrep.java
J org/apache/vysper/xmpp/addressing/Entity.java
J org/apache/vysper/xmpp/addressing/EntityImpl.java
JH org/apache/vysper/xmpp/addressing/EntityConformance.java
J
org/apache/vysper/xmpp/modules/core/im/handler/PresenceAvailabilityHandler.java
J org/apache/vysper/xmpp/modules/core/im/handler/PresenceHandler.java
J
org/apache/vysper/xmpp/modules/core/im/handler/PresenceSubscriptionHandler.java
JH
org/apache/vysper/xmpp/modules/core/im/handler/AbstractPresenceSpecializedHandler.java
J
org/apache/vysper/xmpp/modules/core/base/BaseStreamStanzaDictionary.java
J org/apache/vysper/xmpp/modules/core/base/handler/DefaultIQHandler.java
h
org/apache/vysper/xmpp/modules/core/base/handler/async/RunnableFuture.java
J
org/apache/vysper/xmpp/modules/core/base/handler/async/ResponseFuture.java
j
org/apache/vysper/xmpp/modules/core/base/handler/async/AbstractAsyncIQGetHandler.java
J org/apache/vysper/xmpp/modules/core/base/handler/IQHandler.java
JH
org/apache/vysper/xmpp/modules/core/base/handler/StreamStartHandler.java
J
org/apache/vysper/xmpp/modules/core/base/handler/XMPPCoreStanzaHandler.java
J org/apache/vysper/xmpp/modules/core/base/handler/MessageHandler.java
JH org/apache/vysper/xmpp/modules/core/base/handler/XMLPrologHandler.java
J org/apache/vysper/xmpp/modules/core/bind/handler/BindIQHandler.java
J org/apache/vysper/xmpp/modules/core/bind/BindResourceDictionary.java
J
org/apache/vysper/xmpp/modules/core/sasl/AuthorizationRetriesCounter.java
J org/apache/vysper/xmpp/modules/core/sasl/SASLFailureType.java
J org/apache/vysper/xmpp/modules/core/sasl/SASLStanzaDictionary.java
JH org/apache/vysper/xmpp/modules/core/sasl/handler/AuthHandler.java
JH
org/apache/vysper/xmpp/modules/core/sasl/handler/AbstractSASLHandler.java
JH org/apache/vysper/xmpp/modules/core/sasl/handler/AbortHandler.java
J
org/apache/vysper/xmpp/modules/core/session/SessionStanzaDictionary.java
J
org/apache/vysper/xmpp/modules/core/session/handler/SessionIQHandler.java
J
org/apache/vysper/xmpp/modules/core/compatibility/jabber_iq_auth/JabberIQAuthDictionary.java
J
org/apache/vysper/xmpp/modules/core/compatibility/jabber_iq_auth/handler/AuthCompatibilityIQHandler.java
JH
org/apache/vysper/xmpp/modules/core/starttls/handler/StartTLSHandler.java
J
org/apache/vysper/xmpp/modules/core/starttls/StartTLSStanzaDictionary.java
J
org/apache/vysper/xmpp/modules/servicediscovery/ServiceDiscoveryInfoDictionary.java
J
org/apache/vysper/xmpp/modules/servicediscovery/collection/ServiceDiscoveryRequestListenerRegistry.java
J
org/apache/vysper/xmpp/modules/servicediscovery/collection/ServiceCollector.java
J
org/apache/vysper/xmpp/modules/servicediscovery/ServiceDiscoveryItemDictionary.java
J
org/apache/vysper/xmpp/modules/servicediscovery/management/ServerInfoRequestListener.java
JH org/apache/vysper/xmpp/modules/servicediscovery/management/Item.java
JH
org/apache/vysper/xmpp/modules/servicediscovery/management/Feature.java
JA
org/apache/vysper/xmpp/modules/servicediscovery/management/InfoDataForm.java
JH
org/apache/vysper/xmpp/modules/servicediscovery/management/ServiceDiscoveryRequestException.java
JH
org/apache/vysper/xmpp/modules/servicediscovery/management/InfoElement.java
JH
org/apache/vysper/xmpp/modules/servicediscovery/management/InfoRequest.java
JH
org/apache/vysper/xmpp/modules/servicediscovery/management/Identity.java
J
org/apache/vysper/xmpp/modules/servicediscovery/management/InfoRequestListener.java
J
org/apache/vysper/xmpp/modules/servicediscovery/management/ItemRequestListener.java
J
org/apache/vysper/xmpp/modules/servicediscovery/handler/DiscoItemIQHandler.java
J
org/apache/vysper/xmpp/modules/servicediscovery/handler/DiscoInfoIQHandler.java
J
org/apache/vysper/xmpp/modules/servicediscovery/ServiceDiscoveryModule.java
org/apache/vysper/xmpp/modules/DefaultModule.java
org/apache/vysper/xmpp/modules/ModuleRegistry.java
org/apache/vysper/xmpp/modules/Module.java
org/apache/vysper/xmpp/modules/DefaultDiscoAwareModule.java
JH
org/apache/vysper/xmpp/modules/roster/persistence/AbstractRosterManager.java
J
org/apache/vysper/xmpp/modules/roster/persistence/MemoryRosterManager.java
J org/apache/vysper/xmpp/modules/roster/persistence/RosterManager.java
JH org/apache/vysper/xmpp/modules/roster/RosterUtils.java
J org/apache/vysper/xmpp/modules/roster/SubscriptionType.java
J org/apache/vysper/xmpp/modules/roster/Roster.java
JH org/apache/vysper/xmpp/modules/roster/RosterGroup.java
JH org/apache/vysper/xmpp/modules/roster/RosterStanzaUtils.java
JH org/apache/vysper/xmpp/modules/roster/RosterBadRequestException.java
JH org/apache/vysper/xmpp/modules/roster/RosterException.java
J org/apache/vysper/xmpp/modules/roster/RosterModule.java
JH org/apache/vysper/xmpp/modules/roster/MutableRoster.java
J org/apache/vysper/xmpp/modules/roster/handler/RosterIQHandler.java
J org/apache/vysper/xmpp/modules/roster/RosterSubscriptionMutator.java
J org/apache/vysper/xmpp/modules/roster/RosterItem.java
JH org/apache/vysper/xmpp/modules/roster/RosterConfiguration.java
JH
org/apache/vysper/xmpp/modules/roster/RosterNotAcceptableException.java
JH org/apache/vysper/xmpp/modules/roster/AskSubscriptionType.java
J org/apache/vysper/xmpp/modules/roster/RosterDictionary.java
JH
org/apache/vysper/xmpp/modules/extension/xep0092_software_version/SoftwareVersionIQHandler.java
JH
org/apache/vysper/xmpp/modules/extension/xep0092_software_version/SoftwareVersionModule.java
JH
org/apache/vysper/xmpp/modules/extension/xep0060_pubsub/PubSubPersistenceManager.java
JH
org/apache/vysper/xmpp/modules/extension/xep0060_pubsub/model/MultipleSubscriptionException.java
JH
org/apache/vysper/xmpp/modules/extension/xep0060_pubsub/model/DuplicateNodeException.java
JH
org/apache/vysper/xmpp/modules/extension/xep0060_pubsub/model/CollectionNode.java
jH
org/apache/vysper/xmpp/modules/extension/xep0060_pubsub/model/LeafNode.java
JH
org/apache/vysper/xmpp/modules/extension/xep0060_pubsub/SubscriberVisitor.java
J
org/apache/vysper/xmpp/modules/extension/xep0060_pubsub/AbstractPublishSubscribeIQHandler.java
JH
org/apache/vysper/xmpp/modules/extension/xep0060_pubsub/SubscriberNotificationVisitor.java
JH
org/apache/vysper/xmpp/modules/extension/xep0060_pubsub/handler/PubSubPublishHandler.java
JH
org/apache/vysper/xmpp/modules/extension/xep0060_pubsub/handler/owner/PubSubOwnerConfigureNodeHandler.java
JH
org/apache/vysper/xmpp/modules/extension/xep0060_pubsub/handler/owner/AbstractPubSubOwnerHandler.java
JH
org/apache/vysper/xmpp/modules/extension/xep0060_pubsub/handler/owner/PubSubOwnerDeleteNodeHandler.java
JH
org/apache/vysper/xmpp/modules/extension/xep0060_pubsub/handler/AbstractPubSubGeneralHandler.java
JH
org/apache/vysper/xmpp/modules/extension/xep0060_pubsub/handler/PubSubUnsubscribeHandler.java
JH
org/apache/vysper/xmpp/modules/extension/xep0060_pubsub/handler/PubSubCreateNodeHandler.java
JH
org/apache/vysper/xmpp/modules/extension/xep0060_pubsub/handler/PubSubSubscribeHandler.java
JH
org/apache/vysper/xmpp/modules/extension/xep0060_pubsub/NullPersistenceManager.java
j
org/apache/vysper/xmpp/modules/extension/xep0060_pubsub/PublishSubscribeModule.java
JH
org/apache/vysper/xmpp/modules/extension/xep0054_vcardtemp/VcardTempModule.java
JH
org/apache/vysper/xmpp/modules/extension/xep0054_vcardtemp/VcardTempPersistenceManager.java
JH
org/apache/vysper/xmpp/modules/extension/xep0054_vcardtemp/VcardTempIQHandler.java
JH
org/apache/vysper/xmpp/modules/extension/xep0202_entity_time/EntityTimeModule.java
JH
org/apache/vysper/xmpp/modules/extension/xep0202_entity_time/EntityTimeIQHandler.java
J
org/apache/vysper/xmpp/modules/extension/xep0202_entity_time/EntityTimeXEP0090IQHandler.java
JH
org/apache/vysper/xmpp/modules/extension/xep0049_privatedata/PrivateDataModule.java
JH
org/apache/vysper/xmpp/modules/extension/xep0049_privatedata/PrivateDataPersistenceManager.java
JH
org/apache/vysper/xmpp/modules/extension/xep0049_privatedata/PrivateDataIQHandler.java
org/apache/vysper/xmpp/modules/ServerRuntimeContextService.java
JH org/apache/vysper/xmpp/delivery/LocalDeliveryUtils.java
JH org/apache/vysper/xmpp/delivery/NoSuchLocalUserException.java
J org/apache/vysper/xmpp/delivery/StanzaRelay.java
J org/apache/vysper/xmpp/delivery/StanzaReceiverQueue.java
JH org/apache/vysper/xmpp/delivery/DeliveryException.java
JH
org/apache/vysper/xmpp/delivery/failure/ReturnErrorToSenderFailureStrategy.java
JH org/apache/vysper/xmpp/delivery/failure/IgnoreFailureStrategy.java
J org/apache/vysper/xmpp/delivery/DeliveringInboundStanzaRelay.java
J org/apache/vysper/xmpp/delivery/StanzaReceiver.java
OK org/apache/vysper/xmpp/delivery/DeliveryFailureStrategy.java
J org/apache/vysper/xmpp/delivery/StanzaRelayBroker.java
JA org/apache/vysper/xmpp/delivery/StanzaReceiverRelay.java
J org/apache/vysper/xmpp/delivery/RecordingStanzaRelay.java
JH org/apache/vysper/xmpp/delivery/LocalRecipientOfflineException.java
org/apache/vysper/xmpp/xmlfragment/XMLFragment.java
org/apache/vysper/xmpp/xmlfragment/NamespaceAttribute.java
org/apache/vysper/xmpp/xmlfragment/XMLSemanticError.java
org/apache/vysper/xmpp/xmlfragment/EqualityVerifier.java
org/apache/vysper/xmpp/xmlfragment/FragmentFactory.java
org/apache/vysper/xmpp/xmlfragment/XMLElementVerifier.java
org/apache/vysper/xmpp/xmlfragment/Attribute.java
org/apache/vysper/xmpp/xmlfragment/Renderer.java
org/apache/vysper/xmpp/xmlfragment/XMLElement.java
org/apache/vysper/xmpp/xmlfragment/XMLText.java
org/apache/vysper/xmpp/parser/io/PlainToTLSStreaming.java
org/apache/vysper/xmpp/parser/StringStreamParser.java
org/apache/vysper/xmpp/parser/EncryptionAware.java
org/apache/vysper/xmpp/parser/InputStreamParser.java
org/apache/vysper/xmpp/parser/StreamParser.java
org/apache/vysper/xmpp/parser/ParsingErrorCondition.java
org/apache/vysper/xmpp/parser/ParsingException.java
org/apache/vysper/xmpp/parser/AbstractNekopullStreamParser.java
JH org/apache/vysper/xmpp/cryptography/TLSContextFactory.java
JH org/apache/vysper/xmpp/cryptography/FileBasedTLSContextFactory.java
J org/apache/vysper/xmpp/cryptography/AbstractTLSContextFactory.java
J org/apache/vysper/xmpp/cryptography/BogusTrustManagerFactory.java
JH org/apache/vysper/xmpp/cryptography/TrustManagerFactory.java
org/apache/vysper/xmpp/server/AbstractSessionContext.java
org/apache/vysper/xmpp/server/SessionState.java
org/apache/vysper/xmpp/server/ServerRuntimeContext.java
org/apache/vysper/xmpp/server/response/ServerResponses.java
org/apache/vysper/xmpp/server/response/ServerErrorResponses.java
org/apache/vysper/xmpp/server/DefaultServerRuntimeContext.java
org/apache/vysper/xmpp/server/SessionContext.java
org/apache/vysper/xmpp/server/ServerFeatures.java
org/apache/vysper/xmpp/server/Endpoint.java
org/apache/vysper/xmpp/server/XMPPServer.java
org/apache/vysper/xmpp/server/XMPPVersion.java
org/apache/vysper/xmpp/server/ServerMain.java
org/apache/vysper/xmpp/stanza/Stanza.java
org/apache/vysper/xmpp/stanza/MessageStanzaType.java
org/apache/vysper/xmpp/stanza/IQStanza.java
org/apache/vysper/xmpp/stanza/PresenceStanzaType.java
org/apache/vysper/xmpp/stanza/dataforms/Field.java
org/apache/vysper/xmpp/stanza/dataforms/DataFormEncoder.java
org/apache/vysper/xmpp/stanza/dataforms/DataForm.java
org/apache/vysper/xmpp/stanza/dataforms/Option.java
org/apache/vysper/xmpp/stanza/IQStanzaType.java
org/apache/vysper/xmpp/stanza/MessageStanza.java
org/apache/vysper/xmpp/stanza/StanzaErrorType.java
org/apache/vysper/xmpp/stanza/XMPPCoreStanza.java
org/apache/vysper/xmpp/stanza/StanzaBuilder.java
org/apache/vysper/xmpp/stanza/StanzaErrorCondition.java
org/apache/vysper/xmpp/stanza/PresenceStanza.java
org/apache/vysper/xmpp/stanza/XMPPCoreStanzaVerifier.java
org/apache/vysper/xmpp/writer/StanzaWriter.java
org/apache/vysper/xmpp/writer/SystemOutStanzaWriter.java
org/apache/vysper/xmpp/writer/DenseStanzaLogRenderer.java
org/apache/vysper/xmpp/protocol/StreamErrorCondition.java
org/apache/vysper/xmpp/protocol/SessionStateModifier.java
org/apache/vysper/xmpp/protocol/exception/AuthorizationFailedException.java
org/apache/vysper/xmpp/protocol/exception/TLSException.java
org/apache/vysper/xmpp/protocol/exception/BadXMLException.java
org/apache/vysper/xmpp/protocol/ProtocolException.java
org/apache/vysper/xmpp/protocol/StateAwareProtocolWorker.java
org/apache/vysper/xmpp/protocol/ResponseWriter.java
org/apache/vysper/xmpp/protocol/StanzaHandler.java
org/apache/vysper/xmpp/protocol/ServiceUnavailableStanzaErrorHandler.java
org/apache/vysper/xmpp/protocol/ResponseStanzaContainerImpl.java
org/apache/vysper/xmpp/protocol/SessionStateHolder.java
org/apache/vysper/xmpp/protocol/StanzaHandlerLookup.java
org/apache/vysper/xmpp/protocol/NamespaceURIs.java
org/apache/vysper/xmpp/protocol/QueuedStanzaProcessor.java
org/apache/vysper/xmpp/protocol/ProtocolWorker.java
org/apache/vysper/xmpp/protocol/NamespaceHandlerDictionary.java
org/apache/vysper/xmpp/protocol/worker/EncryptionStartedProtocolWorker.java
org/apache/vysper/xmpp/protocol/worker/EndOrClosedProtocolWorker.java
org/apache/vysper/xmpp/protocol/worker/EncryptedProtocolWorker.java
org/apache/vysper/xmpp/protocol/worker/InitiatedProtocolWorker.java
org/apache/vysper/xmpp/protocol/worker/InboundStanzaProtocolWorker.java
org/apache/vysper/xmpp/protocol/worker/AbstractStateAwareProtocolWorker.java
org/apache/vysper/xmpp/protocol/worker/StartedProtocolWorker.java
org/apache/vysper/xmpp/protocol/worker/AuthenticatedProtocolWorker.java
org/apache/vysper/xmpp/protocol/worker/UnconnectedProtocolWorker.java
org/apache/vysper/xmpp/protocol/HandlerDictionary.java
org/apache/vysper/xmpp/protocol/StanzaProcessor.java
org/apache/vysper/xmpp/protocol/ResponseStanzaContainer.java
OK org/apache/vysper/compliance/SpecCompliance.java
J
org/apache/vysper/compliance/reporting/DocumentSpecCompliantAnnotationFactory.java
OK org/apache/vysper/compliance/SpecCompliant.java
JH org/apache/vysper/storage/jcr/user/JcrUserManagement.java
JH org/apache/vysper/storage/jcr/JcrStorageException.java
JH
org/apache/vysper/storage/jcr/vcardtemp/JcrVcardTempPersistenceManager.java
J org/apache/vysper/storage/jcr/JcrStorage.java
JH org/apache/vysper/storage/jcr/JcrStorageProviderRegistry.java
J org/apache/vysper/storage/jcr/roster/JcrRosterManager.java
JH
org/apache/vysper/storage/jcr/privatedata/JcrPrivateDataPersistenceManager.java
JH org/apache/vysper/storage/StorageProviderRegistry.java
OK org/apache/vysper/storage/StorageProvider.java
JH org/apache/vysper/storage/OpenStorageProviderRegistry.java
J org/apache/vysper/storage/inmemory/MemoryStorageProviderRegistry.java
J org/apache/vysper/stanzasession/StanzaSessionContext.java
JH org/apache/vysper/stanzasession/StanzaSession.java
jA org/apache/vysper/stanzasession/StanzaSessionFactory.java
JHA org/apache/vysper/spring/AddUserHelper.java
J org/apache/vysper/spring/ResourceBasedTLSContextFactory.java
OK org/apache/vysper/spring/ServerMain.java
OK org/apache/vysper/charset/CharsetUtil.java
1 : The @author tag contain some reference to someone, but if the cade
has been included, no reference from the original project
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: Move Vysper from sandbox
Posted by Michael Jakl <ja...@gmail.com>.
Hi!
On Mon, Jun 22, 2009 at 23:33, Bernd Fondermann<bf...@brainlounge.de> wrote:
> Julien Vermillard wrote:
>> On the sandbox moving I think it's a great idea, since the community
>> around Vysper is growing.
>
> I'm +/-0 on this, I trust you guys to decide this.
What about moving projects out of the sandbox with their first public
release? At this time the core of a project should be sufficiently
stable and a wider audience would see a maturing instead of an
emerging project.
I'm not speaking against moving Vysper out of the sandbox (it is quite
stable and its core doesn't change anymore), it's merely an idea
without considering most implications.
Michael
Re: Move Vysper from sandbox
Posted by Emmanuel Lecharny <el...@apache.org>.
Bernd Fondermann wrote:
>>> I don't think every single setter/getter method in Vysper needs javadoc.
>>>
>>>
>> They are typically generated automatically by any decent IDE, it's a no
>> brainer.
>>
>
> That's where we disagree.
> If it's a no brainer, nobody needs it.
>
Well, it's just a placeholder When I use Eclipse (my IDE of choice, most
certainly the best, but, eh, I'm used to it like my old shoes), I
defoine my private fields, and when done for all of them, I just ask
Eclipse to generate all the getters/setters *with* javadoc. Then if I
need to add something in it, I don't have to add all the @ : they are
already there. As I said, an absolute no brainer, and it kills all
discussion with old fart like me who requires Javadoc all over the code ;)
More seriously, I think it's way more important to add some javadoc on
the fields themselves : nothing is more painfull than a field with no
javadoc and a bad selected name :/ However, I can live with a field name
'next' or 'previous' without any Javadoc, if they are used for a cursor
implementation, for instance.
It's all about balance, I think ...
> If there is generated javadoc, you won't have an indication where
> auto-generated doc might not be sufficient.
>
>
>> But you are certainly right on the fact that Javadoc is more important
>> for MINA, as it's more important for commons-XXX than anything else.
>>
>>> In Vysper's commit log history you will notice one or more doc'athons
>>> where a lot of doc is added. I will keep doing that. It's fun.
>>>
>>>
>> I don't think that only one way leads to Rome :)
>>
>
> Yeah, that's right, we won't get into fist fights about javadoc.
> I'm not that type of guy! ;-)
>
I like the idea of a a fight in redcurrent jam, hmm, well, ok, not
applicable to coders, I think :)
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: Move Vysper from sandbox
Posted by Bernd Fondermann <bf...@brainlounge.de>.
Emmanuel Lecharny wrote:
> Bernd Fondermann wrote:
>> Julien Vermillard wrote:
>>
>>> Hi,
>>> The followed rule for MINA Javadoc is :
>>> - a comment in each class header
>>> - doco on each public/protected method (or on the parent class public
>>> method with inherited tags)
>>>
>>> The main point is to help user to understand the public API,
>>> for the internal doco it's more flexible and it's good to hear great
>>> feedback from Michael :)
>>>
>>
>> Let's step back a little bit for a second for some general observations.
>>
>>
> <snip/>
>
>> So, back on topic.
>>
>> I don't think every single setter/getter method in Vysper needs javadoc.
>>
> They are typically generated automatically by any decent IDE, it's a no
> brainer.
That's where we disagree.
If it's a no brainer, nobody needs it.
If there is generated javadoc, you won't have an indication where
auto-generated doc might not be sufficient.
> But you are certainly right on the fact that Javadoc is more important
> for MINA, as it's more important for commons-XXX than anything else.
>> In Vysper's commit log history you will notice one or more doc'athons
>> where a lot of doc is added. I will keep doing that. It's fun.
>>
> I don't think that only one way leads to Rome :)
Yeah, that's right, we won't get into fist fights about javadoc.
I'm not that type of guy! ;-)
Bernd
Re: Move Vysper from sandbox
Posted by Ashish <pa...@gmail.com>.
>>> The main point is to help user to understand the public API,
>>> for the internal doco it's more flexible and it's good to hear great
>>> feedback from Michael :)
>>>
>>
>> Let's step back a little bit for a second for some general observations.
>>
>>
>
> <snip/>
>
>> So, back on topic.
>>
>> I don't think every single setter/getter method in Vysper needs javadoc.
>>
>
> They are typically generated automatically by any decent IDE, it's a no
> brainer.
>>
>> Frankly, I've got better things to do with my time than add redundancies.
>> Often, I sit before a class and think about what I should write into the
>> header javadoc. But nothing good comes to my mind other than repeating
>> what is already in the class name. I keep going on with something else.
>>
>
> <digression>
> Sometime I feel the way you are, when I'm wondering which kind of header I
> can add to explain what does a very basic Class like StringUtils, or a very
> basic method like hexDump( byte[] value ), but at the end of the day, it
> does not harm to drop a single line of comment... Also I'm generally so deep
> into my code that I don't see that someone coming from the outside may need
> some direction.
>
> At the end of the day, it's also something I consider as painful as
> re-reading a letter I wrote to check if I didn't misspelled a word, and
> every time I do that, I discover some missing info, some better method name,
> or even some bug I introduced.
>
> It may be just me, but I feel that Javadoc is as useful as unit-tests. Yeah,
> I know : no fun...
> </digression>
Adding one more dimension to this. We can't assume that everyone shall
use our *Code/Product* the same way. People might be interested in
building things atop our Code/API's, by reusing or extending. Here is
where the documentation helps a lot. Also, a *well* documented code
attracts a large user community (that's an important thing for us) and
possibly lot of committers as well :-)
A very good example could be ApacheDS. You can actually take out lot
of MINA codecs from there like for DNS, DHCP etc, and I am sure
somebody might have used them without using complete code/product.
> But you are certainly right on the fact that Javadoc is more important for
> MINA, as it's more important for commons-XXX than anything else.
>>
>> In Vysper's commit log history you will notice one or more doc'athons
>> where a lot of doc is added. I will keep doing that. It's fun.
>>
>
> I don't think that only one way leads to Rome :)
>
thanks
ashish
Re: Move Vysper from sandbox
Posted by Emmanuel Lecharny <el...@apache.org>.
Bernd Fondermann wrote:
> Julien Vermillard wrote:
>
>> Hi,
>> The followed rule for MINA Javadoc is :
>> - a comment in each class header
>> - doco on each public/protected method (or on the parent class public
>> method with inherited tags)
>>
>> The main point is to help user to understand the public API,
>> for the internal doco it's more flexible and it's good to hear great
>> feedback from Michael :)
>>
>
> Let's step back a little bit for a second for some general observations.
>
>
<snip/>
> So, back on topic.
>
> I don't think every single setter/getter method in Vysper needs javadoc.
>
They are typically generated automatically by any decent IDE, it's a no
brainer.
> Frankly, I've got better things to do with my time than add redundancies.
> Often, I sit before a class and think about what I should write into the
> header javadoc. But nothing good comes to my mind other than repeating
> what is already in the class name. I keep going on with something else.
>
<digression>
Sometime I feel the way you are, when I'm wondering which kind of header
I can add to explain what does a very basic Class like StringUtils, or a
very basic method like hexDump( byte[] value ), but at the end of the
day, it does not harm to drop a single line of comment... Also I'm
generally so deep into my code that I don't see that someone coming from
the outside may need some direction.
At the end of the day, it's also something I consider as painful as
re-reading a letter I wrote to check if I didn't misspelled a word, and
every time I do that, I discover some missing info, some better method
name, or even some bug I introduced.
It may be just me, but I feel that Javadoc is as useful as unit-tests.
Yeah, I know : no fun...
</digression>
But you are certainly right on the fact that Javadoc is more important
for MINA, as it's more important for commons-XXX than anything else.
> In Vysper's commit log history you will notice one or more doc'athons
> where a lot of doc is added. I will keep doing that. It's fun.
>
I don't think that only one way leads to Rome :)
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: Move Vysper from sandbox
Posted by Bernd Fondermann <bf...@brainlounge.de>.
Julien Vermillard wrote:
> Le Sun, 21 Jun 2009 11:22:34 +0200,
> Bernd Fondermann <bf...@brainlounge.de> a écrit :
>
>> Emmanuel Lecharny wrote:
>>> Niklas Gustavsson wrote:
>>>> Hi
>>>>
>>>> For Vysper, the export page has been updated
>>>> (https://issues.apache.org/jira/browse/VYSPER-47), Bernd has
>>>> assembled a list of all contributors
>>>> (https://issues.apache.org/jira/browse/VYSPER-45) and I think we've
>>>> done the due diligence even though the issue is not closed
>>>> (https://issues.apache.org/jira/browse/VYSPER-44). Therefore, I
>>>> think it's time to move Vysper out of the sandbox. If no one
>>>> objects, I'll start a vote in a few days.
>>>>
>>> Well, sorry for being a bit a PITA, but I would like to see more
>>> javadoc in the project. We already have been burnt (and still
>>> are !!!) with MINA suffering from such a problem that I would like
>>> to avoid it again.
>>>
>>> I don't mean it should be perfect, but at least, a first pass is
>>> necessary.
>> Of course we need more javadoc, just as we need more code comments,
>> unit tests, user doc etc. All of that gets my +1.
>>
>> To turn this into an actually task, could you point out areas/classes
>> that especially lack javadoc?
>>
>>> I know this sounds painful, but this is also the price to pay to be
>>> able to jump into the code, to get more committers involved, and to
>>> receive less basic questions on the mailing list.
>> At this point, I'd be happy to actually receive *more* questions ;-)
>>
>> For me, writing javadoc isn't painful at all, when I see something
>> under-documented. I generally consider documentation a quality issue,
>> not a quantity issue.
>>
>> Bernd
>
> Hi,
> The followed rule for MINA Javadoc is :
> - a comment in each class header
> - doco on each public/protected method (or on the parent class public
> method with inherited tags)
>
> The main point is to help user to understand the public API,
> for the internal doco it's more flexible and it's good to hear great
> feedback from Michael :)
Let's step back a little bit for a second for some general observations.
MINA is a 'framework', a 'toolset'. Other people use it as a basic
foundation to build their own stuff on it. They don't install it in the
classical way, they don't configure it like a server would typically be
configured. Instead, they download it and dive in. They have to know how
everything/most of it works. There is no other documentation than what's
on mina.apache.org. They have to rely on the javadoc to figure things
out. (BTW, there are not many exhausting MINA examples, that's something
that concerns me more than the javadoc.)
Vysper is a 'server'. It's a standalone application which gets
installed, configured and monitored in a very classical way.
It's an implementation of a well-defined standard (RFCs and XEPs).
People download it, but I don't expect that Vysper's users will get a
very deep understanding of it. Developers can (should/must) consult the
XMPP specs which explains everything very precise. That's why Vysper has
@SpecCompliant annotations and MINA hasn't. If you look at Vysper code
and haven't read RFCs 3920 + 3921, you probably will run into troubles
understanding it.
Conclusion: MINA and Vysper are very different.
So, back on topic.
I don't think every single setter/getter method in Vysper needs javadoc.
Frankly, I've got better things to do with my time than add redundancies.
Often, I sit before a class and think about what I should write into the
header javadoc. But nothing good comes to my mind other than repeating
what is already in the class name. I keep going on with something else.
In Vysper's commit log history you will notice one or more doc'athons
where a lot of doc is added. I will keep doing that. It's fun.
>
> Anyway the javadoc issue could be blocking for a 1.0 release, but
> looks like we aren't there :)
No, were aren't there by far. A 0.1 is more what I have in mind, but
this will still take some time, too.
>
> On the sandbox moving I think it's a great idea, since the community
> around Vysper is growing.
I'm +/-0 on this, I trust you guys to decide this.
Bernd
Re: Move Vysper from sandbox
Posted by Julien Vermillard <jv...@archean.fr>.
Le Sun, 21 Jun 2009 11:22:34 +0200,
Bernd Fondermann <bf...@brainlounge.de> a écrit :
> Emmanuel Lecharny wrote:
> > Niklas Gustavsson wrote:
> >> Hi
> >>
> >> For Vysper, the export page has been updated
> >> (https://issues.apache.org/jira/browse/VYSPER-47), Bernd has
> >> assembled a list of all contributors
> >> (https://issues.apache.org/jira/browse/VYSPER-45) and I think we've
> >> done the due diligence even though the issue is not closed
> >> (https://issues.apache.org/jira/browse/VYSPER-44). Therefore, I
> >> think it's time to move Vysper out of the sandbox. If no one
> >> objects, I'll start a vote in a few days.
> >>
> >
> > Well, sorry for being a bit a PITA, but I would like to see more
> > javadoc in the project. We already have been burnt (and still
> > are !!!) with MINA suffering from such a problem that I would like
> > to avoid it again.
> >
> > I don't mean it should be perfect, but at least, a first pass is
> > necessary.
>
> Of course we need more javadoc, just as we need more code comments,
> unit tests, user doc etc. All of that gets my +1.
>
> To turn this into an actually task, could you point out areas/classes
> that especially lack javadoc?
>
> > I know this sounds painful, but this is also the price to pay to be
> > able to jump into the code, to get more committers involved, and to
> > receive less basic questions on the mailing list.
>
> At this point, I'd be happy to actually receive *more* questions ;-)
>
> For me, writing javadoc isn't painful at all, when I see something
> under-documented. I generally consider documentation a quality issue,
> not a quantity issue.
>
> Bernd
Hi,
The followed rule for MINA Javadoc is :
- a comment in each class header
- doco on each public/protected method (or on the parent class public
method with inherited tags)
The main point is to help user to understand the public API,
for the internal doco it's more flexible and it's good to hear great
feedback from Michael :)
Anyway the javadoc issue could be blocking for a 1.0 release, but
looks like we aren't there :)
On the sandbox moving I think it's a great idea, since the community
around Vysper is growing.
Julien
Re: Move Vysper from sandbox
Posted by Emmanuel Lecharny <el...@apache.org>.
Bernd Fondermann wrote:
> Emmanuel Lecharny wrote:
>
>> Niklas Gustavsson wrote:
>>
>>> Hi
>>>
>>> For Vysper, the export page has been updated
>>> (https://issues.apache.org/jira/browse/VYSPER-47), Bernd has assembled
>>> a list of all contributors
>>> (https://issues.apache.org/jira/browse/VYSPER-45) and I think we've
>>> done the due diligence even though the issue is not closed
>>> (https://issues.apache.org/jira/browse/VYSPER-44). Therefore, I think
>>> it's time to move Vysper out of the sandbox. If no one objects, I'll
>>> start a vote in a few days.
>>>
>>>
>> Well, sorry for being a bit a PITA, but I would like to see more javadoc
>> in the project. We already have been burnt (and still are !!!) with MINA
>> suffering from such a problem that I would like to avoid it again.
>>
>> I don't mean it should be perfect, but at least, a first pass is necessary.
>>
>
> Of course we need more javadoc, just as we need more code comments, unit
> tests, user doc etc. All of that gets my +1.
>
> To turn this into an actually task, could you point out areas/classes
> that especially lack javadoc?
>
I quickly checked the code, so I don't have a list right now. However,
the process to follow is :
- check all the classes with no header
- Javadoc is absolutely mandatory for Interfaces. Using an @inherited
annotation for implementing classes is always a good way to know that
the javadoc is written in the interface.
- Javadoc for private fields is also needed.
I will try to get a list this afternoon, as I will take a train and
won't have a network connection.
>
>> I know this sounds painful, but this is also the price to pay to be able
>> to jump into the code, to get more committers involved, and to receive
>> less basic questions on the mailing list.
>>
>
> At this point, I'd be happy to actually receive *more* questions ;-)
>
yeah, don't worry, it will happen :)
> For me, writing javadoc isn't painful at all, when I see something
> under-documented. I generally consider documentation a quality issue,
> not a quantity issue.
>
Totally +1.
> Bernd
>
>
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: Move Vysper from sandbox
Posted by Bernd Fondermann <bf...@brainlounge.de>.
Emmanuel Lecharny wrote:
> Niklas Gustavsson wrote:
>> Hi
>>
>> For Vysper, the export page has been updated
>> (https://issues.apache.org/jira/browse/VYSPER-47), Bernd has assembled
>> a list of all contributors
>> (https://issues.apache.org/jira/browse/VYSPER-45) and I think we've
>> done the due diligence even though the issue is not closed
>> (https://issues.apache.org/jira/browse/VYSPER-44). Therefore, I think
>> it's time to move Vysper out of the sandbox. If no one objects, I'll
>> start a vote in a few days.
>>
>
> Well, sorry for being a bit a PITA, but I would like to see more javadoc
> in the project. We already have been burnt (and still are !!!) with MINA
> suffering from such a problem that I would like to avoid it again.
>
> I don't mean it should be perfect, but at least, a first pass is necessary.
Of course we need more javadoc, just as we need more code comments, unit
tests, user doc etc. All of that gets my +1.
To turn this into an actually task, could you point out areas/classes
that especially lack javadoc?
> I know this sounds painful, but this is also the price to pay to be able
> to jump into the code, to get more committers involved, and to receive
> less basic questions on the mailing list.
At this point, I'd be happy to actually receive *more* questions ;-)
For me, writing javadoc isn't painful at all, when I see something
under-documented. I generally consider documentation a quality issue,
not a quantity issue.
Bernd
Re: Move Vysper from sandbox
Posted by Emmanuel Lecharny <el...@apache.org>.
Niklas Gustavsson wrote:
> Hi
>
> For Vysper, the export page has been updated
> (https://issues.apache.org/jira/browse/VYSPER-47), Bernd has assembled
> a list of all contributors
> (https://issues.apache.org/jira/browse/VYSPER-45) and I think we've
> done the due diligence even though the issue is not closed
> (https://issues.apache.org/jira/browse/VYSPER-44). Therefore, I think
> it's time to move Vysper out of the sandbox. If no one objects, I'll
> start a vote in a few days.
>
Well, sorry for being a bit a PITA, but I would like to see more javadoc
in the project. We already have been burnt (and still are !!!) with MINA
suffering from such a problem that I would like to avoid it again.
I don't mean it should be perfect, but at least, a first pass is necessary.
I know this sounds painful, but this is also the price to pay to be able
to jump into the code, to get more committers involved, and to receive
less basic questions on the mailing list.
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org