ashokpant / dkpro-tc

Automatically exported from code.google.com/p/dkpro-tc
Other
0 stars 0 forks source link

Use simple artifactIds #152

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
I have changed the artifactIds in DKPro Lab to the standard simple IDs that use 
dashes instead of dots for separation and that do not repeat the full groupId.

E.g. now

  <groupId>de.tudarmstadt.ukp.dkpro.lab</groupId>
  <artifactId>dkpro-lab</artifactId>

instead of previously

   <groupId>de.tudarmstadt.ukp.dkpro.lab</groupId>
   <artifactId>de.tudarmstadt.ukp.dkpro.lab</artifactId>

This requires updates in the DKPro TC dependencies. 

I would also suggest to change the DKPro TC artifactIds into simple IDs. But 
please to not change the groupId. It must resemble a kind of "domain name" and 
should stay "de.tudarmstadt.ukp.dkpro.tc".

If you change the artifactIds, please also change the subfolder names of the 
modules to resemble the new artifact IDs and update the <module> section in the 
parent POM. Eclipse can get confused if the subfolder name does not match the 
artifactIds of the module in that folder.

Original issue reported on code.google.com by richard.eckart on 18 Jun 2014 at 12:06

GoogleCodeExporter commented 9 years ago
Just out of curiosity: What is the advantage of the new scheme? :)

Original comment by torsten....@gmail.com on 18 Jun 2014 at 8:26

GoogleCodeExporter commented 9 years ago
It's the standard scheme for Maven and it is shorter ( e.g. when writing Groovy 
scripts ;) ).

The reasons would be, we did we not always use that scheme. The reason is that 
OSGi has a different scheme (the one we use). Back in the day I know less about 
Maven and was expecting OSGi to be something important to us in the mid term. 
However, time has proven this expectation not to be correct.

Original comment by richard.eckart on 18 Jun 2014 at 9:00

GoogleCodeExporter commented 9 years ago
If we decide to change the artifact ids, we should do it before the release, so 
that they stay stable from then on. What's the general opinion? Should I make 
these changes now?  

Original comment by oliver.ferschke on 18 Jun 2014 at 10:02

GoogleCodeExporter commented 9 years ago
DKPro Core will transition to the new scheme too
https://code.google.com/p/dkpro-core-asl/issues/detail?id=186

So it makes sense to do that now. Any objections?

Original comment by oliver.ferschke on 18 Jun 2014 at 10:06

GoogleCodeExporter commented 9 years ago
REC also brought up the issue whether to get rid of the -ASL and -GPL suffixes 
to get more readable IDs.
It's a tradeoff - people have to look into a module (or some overview on the 
project page) to see what license a module has, but the shorter ids are much 
nicer if the end with the actual module name,

e.g. 
dkpro-tc-features-ngram
instead of 
dkpro-tc-features-ngram-asl
instead of 
de.tudarmstadt.ukp.dkpro.tc.features.ngram-asl

Original comment by oliver.ferschke on 18 Jun 2014 at 10:23

GoogleCodeExporter commented 9 years ago
I guess people who really care about licenses will do the extra step :)

Original comment by torsten....@gmail.com on 18 Jun 2014 at 11:53

GoogleCodeExporter commented 9 years ago
Good. I am currently making the changes locally on my machine. I'll report 
again when I'm done before doing any commits.

Original comment by oliver.ferschke on 18 Jun 2014 at 11:57

GoogleCodeExporter commented 9 years ago
Well, we should care. Before doing a release, it would be good to check if 
somebody accidentally introduced a GPL dependency to an ASL module. But whether 
we check the POM or the dependency report is probably wurscht. In fact, the 
dependency report is probably more detailed and may also catch third-party 
dependencies accidentally introduced.

Original comment by richard.eckart on 18 Jun 2014 at 11:57

GoogleCodeExporter commented 9 years ago
This issue was closed by revision r901.

Original comment by oliver.ferschke on 18 Jun 2014 at 1:02