Regarding java8 and java7 artifacts …

This could be problematic, if we wanted to publish both.

Having a binary tar.gz with a java8 and one with java7 doesn’t seem to be a 
problem, but having two artifacts deployed to Maven-Central is no trivial task.
Exactly this type of jars for different java versions is one of the things the 
Maven guys are currently working on as part of the Java 9 – Jigsaw support. But 
it’s a nightmare. We could start creating java8 jars as default and add a 
second “java7” jar using the “java7” classifier, but then a lot of the 
mechanisms in Maven no longer work. 

I could offer to generally build java7 versions and to test them with java7 and 
java8 … I think this topic should be discussed a little more before I start 
implementing this.

Right now, I would opt for distributing java8 binaries to Maven Central and to 
offer downloadable java7 binary distributions.

Chris



Am 07.06.17, 21:06 schrieb "Christofer Dutz" <[email protected]>:

    Hi,
    
    Right now I didn't configure anything regarding the assembly of the source 
artifact. It's apaches default config. I'll look into a more fine-tuned version.
    
    And regarding the artifact name ... Justin suggested that change, but 90% 
of the other projects don't do it that way. I was waiting for your opinions 
before doing that. It does make the dependencies a lot more verbose. After all 
you can't use the artifacts without the groupId "org.apache.effect" which 
includes "apache" and "edgent".
    
    But sure, I'll change that if you all want me to.
    
    Chris
    
    Von meinem Samsung Galaxy Smartphone gesendet.
    
    
    -------- Ursprüngliche Nachricht --------
    Von: Dale LaBossiere <[email protected]>
    Datum: 07.06.17 18:45 (GMT+01:00)
    An: [email protected]
    Betreff: Re: Understanding the snapshot and release process
    
    OK, so mvn install -Papache-release generates the source release bundle zip.
    
    I poked around for a while but couldn’t come up with the incantation
    needed to start excluding things from the zip.  e.g., the zip includes
    all of the residual gradle generated **/build/
    
    Chris, can you enhance the configs so as to exclude the various
    things that the gradle build was configured to exclude?
    See top level build.gradle/srcReleaseTarGz task.
    Also exclude src/site (that present in the zip too), right?
    
    The generated zip’s name is:
          target/edgent-parent-1.2.0-SNAPSHOT-source-release.zip
    
    “edgent-parent” ?  today we, I thought correctly, have “apache-edgent” 
there.
    Also, the required “incubating” is missing in the release bundle name.
    
    Thanks,
    — Dale
    
    > On Jun 7, 2017, at 10:35 AM, Christofer Dutz <[email protected]> 
wrote:
    >
    > Checking our repo:
    > https://repository.apache.org/#view-repositories;releases~browsestorage
    >
    > I can see that fewer than about 10% of all apache projects do that … But 
I wouldn’t mind adding that, if the others agree.
    >
    > Chris
    >
    >
    >
    > Am 07.06.17, 14:54 schrieb "Justin Mclean" <[email protected]>:
    >
    >    Hi,
    >
    >    While not a requirement prefixing with apache may add some legal 
protection and is good from a branding point of of view.
    >
    >    Thanks,
    >    Justin
    >
    
    

Reply via email to