Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Where is the package "de.jollyday.config" on GitHub? #59

Closed
MenoData opened this issue Nov 21, 2017 · 7 comments
Closed

Where is the package "de.jollyday.config" on GitHub? #59

MenoData opened this issue Nov 21, 2017 · 7 comments

Comments

@MenoData
Copy link

Some classes like EthiopianOrthodoxHolidayParser refer to the package (for example to the class de.jollyday.config.Holidays) but I cannot find the package - neither on GitHub nor on downloaded zip-files from GitHub. I think, an open-source-project is supposed to contain all source code, or have I overlooked something?

Background is, I would like to contribute for example Hebrew holidays in the future but then I need to see and understand the whole source code...

@MenoData
Copy link
Author

MenoData commented Nov 21, 2017

Okay, it is dynamically created via xml-binding but I still see the disadvantage not to have reasonable good javadocs and source code navigation. Question: Is excluding the package from javadoc really necessary?


141                 <plugin> 
142                     <groupId>org.apache.maven.plugins</groupId> 
143                     <artifactId>maven-javadoc-plugin</artifactId> 
144                     <version>2.10.4</version> 
145                     <configuration> 
146                         <excludePackageNames>de.jollyday.config</excludePackageNames> 
147                     </configuration> 
148                 </plugin> 

@svendiedrichsen
Copy link
Owner

Classes under de.jollyday.config don't contain any logic. They are simple DTO classes which are used by JAXB for deserializing XML files. They only carry generated javadoc and anntotations and will never be checked in as normal source code is. Including these into generated javadoc will not provide any insight into how the API work but will distract from working code.

@MenoData
Copy link
Author

I see your point. So that package is some kind of implementation internals. But I also still see the problem that other parts of public API refer to the package de.jollyday.config, for example:

http://jollyday.sourceforge.net/apidocs/de/jollyday/util/CalendarUtil.html#create-int-de.jollyday.config.Fixed-

IMHO, a public API should not refer to internals. This has first made it difficult for me to understand your API, and introducing new public interfaces might solve the problem, but of course, you are free to close this issue without action if it is too much work for you.

@svendiedrichsen
Copy link
Owner

I'm open to any suggestions. Please feel free to fork and rework apropriately.

@MenoData
Copy link
Author

Okay, I will try to make some proposals in code form later (but probably rather in the begin of year 2018 when I can also contribute holidays in Israel).

@MenoData
Copy link
Author

MenoData commented Dec 5, 2017

By the way, have you noticed that Oracle seems to be willing to delete the javax.xml.bind-package from JDK? Java-9 has this information about the associated module:

@Deprecated(since="9", forRemoval=true) 
Module java.xml.bind

Here an official link: http://openjdk.java.net/jeps/320

It would probably affect Jollyday so I thought it is good for you to know for the future.

@svendiedrichsen
Copy link
Owner

Thank you. Good to know.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants